Filters can be used as a sort of a “set up your own layers” system. If I think (as many mappers do) that landuse areas shouldn’t be connected to road lines then I can treat them as separate layers using filters. However, if I edit an area where another mapper has connected roads and landuse with my pseudo layer system of filters active, I may inadvertently change road geometry while only intending to modify landuse. With a true layer system there would have to be consensus that these two feature types should never be connected and the tools would ensure that it didn’t happen. So not exactly the same.
3 Likes
As it happens, this example that I shared earlier is one spot where the Central–Mountain time zone boundary is defined to run along the centerline of a highway. You observe Central Time going northbound and Mountain Time going southbound. If the state needs to shift the highway slightly to the east for some reason, presumably with the consent of the tribal authorities or BIA, then the boundary automatically moves along with it. For this reason, I glued the boundary way to the roadway. Sorry.
Granted, this is in such a remote spot that, if we were to detach the boundary and allow it to get misaligned slightly, not too many motorists would see an OSM-based router estimate an arrival time that’s off by an hour.
Let’s just be thankful no one has put this proposal into practice yet:
2 Likes
Would it be acceptable to limit timezone mapping to only IANA timezones? That would limit timezones to large, but not world-spanning relations. It would be easier to track for completeness than tagging boundaries of rural municipalities. And it would be consistent, so we could easily notice timezone tags that don’t fit the standard.
I would be disappointed that there would no longer be a way to view all areas of the world that share a timezone, but at least people who know how to make maps from aggregates of data could do so.
1 Like
I’m frankly surprised we’re hand-wringing about these puny time zone boundaries when Tongass National Park exists as the standard-bearer of difficult-to-process large polygons.
3 Likes
no need to say sorry (it was ironic anyway, was it?), this is exactly a great real life example how things are connected and how our model allows to preserve the topology.
Maybe the untagged way should be replaced in the timezone relations with this?
Or is it sufficient that nodes are shared?
Hard cases make bad law. For every single case where, to quote the wiki…
An exception may be done if the boundary is legally defined to be the physical feature.
…there are a thousand ones where well-meaning mappers abused an existing map feature as a boundary line, either directly or by gluing, which invariably creates a untangleable mess whenever one wants to edit the map. Thank you very much, in those strange cases I’d rather duplicate the geometry and update it after every unlikely event such as earthquake or catastrophic flood that may have moved it.
We just need to tag the roadway with note=READ ME FIRST: Remember to update way 1032433038 in the other layer if you touch this way!!! and scold anyone who doesn’t follow the instructions. And if someone wants to know which boundaries are tied to roadways, all they have to do is look for exclamation marks. 
At least that road is built infrastructure that changes deliberately. Maybe the roadgeek community would be able to keep tabs on when the road gets realigned. On the other hand, this waterway can certainly be affected by a hurricane; it forms the boundary between the Eastern and Central time zones.
But to your point, these non-administrative portions of a time zone boundary are the exception rather than the rule. I bring them up only to illustrate the difference between an observed time and a time zone.
Perhaps an even more relevant illustration of this distinction is that not all of the Mountain Time Zone observes the same time: during the summer months, Mountain Daylight Time is observed throughout the Mountain Time Zone, except for Arizona, double-except for the portions of the Navajo Nation within Arizona, triple-except for the Hopi Reservation (an enclave within the Navajo Nation). This map gives a sense of the complexity, though it omits the fact that the three states overlap the entirety of the Navajo Nation:
These are state and tribal boundaries, not time zone boundaries. You won’t find an “Entering … Time Zone” sign at the edge of the reservation. But the IANA and tz database have carved out Arizona as its own “time zone” due to its decision not to observe daylight saving time. The Mountain Time Zone relation currently excludes Arizona; this is one reason it has a name of “America/Denver” instead of the more recognizable and groundtruthable “Mountain Time Zone”. I’ve been wondering if we should represent that distinction differently, maybe with tags on administrative boundaries, but the Navajo Nation boundary makes it difficult to come up with a sensible boundary topology.
Just to emphasise how much of a pain these are to anyone who monitors anything near them: the UTC-5 relation has a history that is unloadable in the browser.
I get this error on osm.org/relation/13514841/history:
Timeout Error
Sorry, the data for the relation with the id 13514841, took too long to retrieve.
If the way we model them causes the main site to fail I think we’re doing it wrong.
At just over 2 years old it is on version 207, the average version doesn’t even last a full 4 days.
This is madness.
As pointed out above, the U.S. has a national park that causes the same error, just to load the 29,000-member-strong relation itself, not even its history. (Fixing our country is on the to-do list.)
With a whopping 1,774 members, this relation is quite an outlier. The average boundary=timezone relation has only 295 members, putting it 24th among boundary=* types. Its average member count is higher than any other relation with 100 or more occurrences, but only slightly. Compared to various route relation types, boundary=timezone is quite unremarkable.
A UTC offset isn’t really a time zone, even though some maps depict them like time zones. I wonder if we can find a middle ground that would treat the world-spanning UTC offset relations differently than the boundary=timezone relations that represent more observable, named zones. The U.S. time zone boundaries I’ve been harping on about aren’t nearly so large – their size is merely a function of the country’s size.
2 Likes
fair warning: trying to open this relation on the OSM website a couple times will get your IP ratelimited. Was a little confused what happened until I looked in the console, haha
As someone who has been maintaining timezone boundaries, I can speak to the tradeoffs of adding timezone tags to numerous administrative boundaries versus having a single large relation.
Initial effort: There isn’t much of a difference here, for the largest timezones it’s going to take a bunch of time from either the single relation or multiple admin boundaries strategy.
Forced refactor to either strategy: If being forced to refactor from one strategy to the other, this will take quite some time in either direction as there are some timezone boundaries compiled as a single relation (eg the America/Central, etc), but then there are also others such as Vietnam (Asia/Ho_Chi_Minh) which has timezone tags on various administrative relations.
Easy of querying via Overpass: No difference.
Amount of data transferred from Overpass: The single relation method will result in significantly less data being transferred. As seen in the Vietnam example, all of the ways in the inner part of the polygon are not needed. The advantage of the single relation is that it is much easier to focus exclusively on only the elements needed to make the timezone boundary.
Ease of editing in OpenStreetMap: The single-relation option is a little easier. It is possible to query for multiple different relations in JOSM when downloading, but then it can result in larger changesets affecting a greater amount of objects in order to get the timezones right.
The timezone project for me has been an interest of mine that has likely resulted in me editing and improving/fixing a large number of other objects that were not the primary focus of my timezone work. I don’t know whether these relations are causing more harm for others, but I am grateful that they have existed in OpenStreetMap.
I also appreciate the work others have contributed towards improving boundaries of various things that the timezone boundaries share such that all that can be brought in along with the timezone boundary data that gets published. The accuracy of various borders in OpenStreetMap was the original impetus for the creation of the timezone-boundary-builder project and that was back in 2016.
1 Like
Well, that was true when I wrote it, but you all nerd-sniped me hard enough to send me on a monthlong detour into time zone mapping. 
I spent most of the month drawing the old boundaries from scratch based on railroad tracks rather than any kind of administrative boundary. Actually, not the tracks themselves, but rather the edges of the rights of way of those tracks, some of them already abandoned or submerged under a reservoir at the time, unbeknownst to the federal government. Despite having gotten a firsthand look at the darkened crop lines and suspected embankments that OSM’s abandoned railway mappers swear by, I still don’t really get the appeal for them in OSM when something like this can happen to a mainline:
As excited as I am about OHM becoming a destination for exotic geographic knowledge, OSM’s definition of a “time zone” differs enough from OHM’s that the two projects will continue to complement each other for the foreseeable future. OSM’s boundary=timezone relations and timezone=* tags on administrative boundary relations make it relatively straightforward to determine the correct Internet time zone for a given place in the present day:
By constrast, OHM takes a longer view that will be useful for placing events further back in history – that is, once Wikidata figures out how to modeling daylight saving time and other quirks of observed time that don’t necessarily conform to boundaries. OHM is more interested in real-world history than the history of the tz database, but that database has such an impact on modern life that OSM benefits from integrating with it even more than from covering some real-world boundaries.
Having gone through this exercise, I’m not inclined to replicate in OHM the giant, pole-to-pole “time zone” boundaries that prompted this thread’s revival. Real time zone boundaries don’t fit into that model very well, and others have noted the unnecessarily high maintenance overhead associated with them. I mean, even the puny U.S. time zone boundaries forced me out of iD and into JOSM – that’s saying something.
Incidentally, I noticed that @Arctic_gnome has experimented with transnational timezone_master relations. What is the intended definition of this relation type? The “Eastern Time Zone” boundary relation still seems to model more or less the pole-to-pole UTC−5 region, including not only the jurisdictions that call it the Eastern Time Zone but also those that define a matching time offset as a national civil time. It could be a workable alternative to the pole-to-pole relations, but a different name would avoid some confusion.
2 Likes
There seemed to be consensus that we don’t want pole-to-pole timezones. But I still liked the idea of a relation that showed all regions using the same time. My suggestion is to use a timezone master relation that groups all IANA timezones that have now become identical to each other. Alternatively, it could group zones that have the same standard time but different daylight savings times. Either version of the master timezone would have the same benefit as pole-to-pole zones while being easier to maintain. The only downside is that there is no way to view master relations on OSM’s website without tools.
In other words, the time zone master relation would represent all the regions with the same UTC offset (modulo DST), or alternatively a real-world time zone boundary (composed of IANA time zones). Should the two concepts share the same tagging combination?
The wiki still recommends tagging time zone relations with utc=*, representing the UTC offset, but hardly any relations are tagged with that anymore. If they were, then you’d be able to run a simple Overpass API query in Overpass turbo or Overpass Ultra to visualize these regions. The only thing that doesn’t have a representation in OSM is the real-world time zone boundaries, which are what OHM is currently covering.