This example seems perfectly fine to me.
However, creating relations for “timezone A in the world” and “timezone B in the world” would be unnecessarily complicated.
Technically, the tz database tracks a time zone’s various additions and removals past a certain date. It has a separate entry for America/Indiana/Vincennes because those four counties of southwestern Indiana have shared a common time zone history since 1970 (observing Central Time from 1977 to November 2007). This differs from how either OSM or OHM conceptualizes boundaries. For example, when a city annexes surrounding territory, we represent the resulting boundary as a single feature rather than mapping the annexation per se.
For example, OHM imported San José’s territorial evolution from a dataset that tracked individual annexations by date. Most of the features in the dataset are individual parcels. But we processed the data so that each boundary relation represents what was considered to be the city limits on a given day. You’d need to diff two of the boundaries to get the set of annexations that occurred on the same day. OHM could do something similar with time zone boundaries to arrive at geometries that correspond one-for-one with more of the tz database entries than OSM would ever be able to represent.
But you’re absolutely right that OHM would need to consult more sources beyond the tz database. One of the primary differences between OSM and OHM is that OHM welcomes verifiable geodata whether someone geeks out about century-old etchings in the slab of concrete they’re standing on, traces an out-of-copyright map, imports boundaries that were valid for all of three days in 1960, or consults an archaeological survey. In my view, OHM will inevitably incorporate time zone boundaries, regardless of what OSM does with them. I suppose that’s a win-win from a certain perspective.
From this explanation, it sounds like the concern is the maintenance overhead of keeping the boundary intact. I can only speak for the U.S. where I’ve mapped time zone boundaries, but this goes somewhat beyond the status quo and seems counterproductive to me. The Central Time Zone (or “America/Chicago”, as the tz database calls it) incorporates 15 ways that don’t correspond to any administrative boundary. All of them are pretty straightforward. If anyone breaks the time zone boundary elsewhere, they’ll most likely also break an administrative boundary at the same time, so there’s no additional maintenance overhead.
The status quo is that there’s a single boundary relation representing the Central Time Zone. You’re proposing to dissolve this boundary relation into timezone=* tags on ten state boundary relations, 84 Indian reservation boundaries, and 1,028 county boundary relations (65 FL, 92 IN, 105 KS, 120 KY, 83 MI, 47 ND, 93 NE, 95 TN, 64 SD, 254 TX), then create 12 new timezone boundary relations to represent “X Time Zone in Y County” and “X Time Zone on Y Reservation” along non-administrative portions of the boundary. None of these relations would correspond to real-world concepts, being artifacts of OSM’s chosen data model.
Thus, what is universally regarded as a single geographic feature in reality would instead be represented by 1,134 distinct elements in OSM. That’s 358 more elements than are members of the current boundary relation – 32% more. Instead of using a conventional tool such as Overpass to determine whether the boundary is closed, we’ll need to do something custom to union the 1,134 geometries together and determine whether there are any holes.
For what it’s worth, I’m no time zone geek. I patch up what I need to, so that OSM has the basics, and retreat as fast as I can. Maintaining comprehensive time zone data is a full-time professional job that I don’t need. But I care about either OSM or OHM having present-day time zone boundaries, because they’re a standard part of a general-interest map. You’d be hard-pressed to find a political map, road map, or rail map of the U.S. in print that lacks time zone boundaries, and I hope that Americana will also get there someday.
@EvanSiroky was referring to a situation where a locality keeps a different time unofficially than it does officially. I’m familiar with this situation, having grown up just across the border from a county in Indiana that kept “official time” (Central) and “commercial time” (Eastern). The very classic OSM approach would be to map what’s on the ground: that is, include the county in the Eastern Time Zone per the signs but simultaneously include it in the Central Time Zone per the clock on every wall. The locals would love our approach to local knowledge.
I accept that this differs markedly from the experience in some other parts of the world, where time zones conveniently fall under the “Don’t map local legislation” principle. But I look at the slippery slope argument with some skepticism, because the reality is that timekeeping practices do differ from region to region.
4 Likes
Can I ask a dumb question?
If a time zone is generally an area composed of administrative areas, and administrative areas are defined by boundary relations, wouldn’t it be easy to group the administrative areas as relation members into a timezone relation?
Wouldn’t that prevent having to put a timezone tag on every single member, and prevent also having to create monster timezone boundary relations with thousands of way members?
In that case, the Central Time Zone relation would be a monster relation with 1,134 relation members instead of the current 776 way members. It’s bad enough that some mappers see the need to stuff a boundary relation with the relations of all its subdivisions as subarea members, but at least all those subareas are actually related to each other. From a technical standpoint, this would be more like mapping a relation of all the countries and subnational regions that drive on the left, or all the U.S. cities, counties, and states that have banned plastic shopping bags.
It would be especially ironic because the U.S. has never conceptualized a time zone as a property of another administrative subdivision, but rather a zone with its own boundaries. The boundaries happen to coincide with administrative subdivisions most of the time, just as state boundaries generally align with county boundaries – not pure happenstance, but not quite the same feature.
6 Likes
Really? I’m surprised. I thought, most countries go as 1 each, except where a country has multiple time zones then you go by state. Only when a state has multiple timezones, you go by county for that state. When state time divisions occur often, the number of members rises very quickly, I can see that, but 1134?
You’re right, I copy-pasted the 1,134 figure from my response above, but I forgot that that figure represents the number of elements that need to be tagged with a timezone due to dissolving the Central Time Zone, including plenty of counties in the neighboring Mountain and Eastern time zones. So while the figure is still a stark rebuttal to the original relation-less proposal, it isn’t relevant to the relation you’re describing. Sorry for the confusion.
If we were to model the Central Time Zone relation as you describe, then it would have these 631 boundary relations as subarea members, plus the 12 artificial timezone boundaries along non-administrative features. So there would be a 17% reduction in the number of members in this relation.
Meanwhile, the Mountain Time Zone relation would have these 135 members, plus 16 synthetic boundary relations along these non-administrative features, representing a 74% reduction.
Nevertheless, I think my other points stand:
- This sort of relation would clearly run afoul of the “Relations are not categories” principle. What do the Town of West Wendover in Nevada, Tooele County in Utah, and the State of Colorado have to do with Dunn County in North Dakota, other than the fact that all happen to observe Mountain Time and lie within the real-world Mountain Time Zone boundary?
- This modeling makes it more difficult to determine whether there are any gaps in the relation. If today’s relation is fragile, imagine the same fragility but more difficult to detect.
What’s more, in order to load the actual real-world time zone boundary’s geometry, you have to load an inordinate number of county and state boundary ways that don’t run along the actual boundary. This slimmed-down Mountain Time Zone relation may have only 151 members, but you’d have to recursively load around 5,695 ways representing a superset of the geometry. I’m not talking about what it takes to turn the geometry into something useful; this is just what it takes to load the whole relation, so you don’t end up breaking it while editing something unrelated.
The desire for optimization is commendable, but this feels like overengineering to me.
6 Likes
Thanks for making me understand the matter. I can see why it has a high PITA-potential. And I understand that tagging of the zones themselves as areas or boundaries is far more direct and manageable than breaking them down into pieces that have to be pieced together ever time someone wants to do anything with time zones.
Should OSM hold this information in the database?
Well, people can do that, if they like, the question is: is there enough ground truth and verifiability. I think all time zones have enough public time devices to say there is ground truth. It’s more about precision: where exactly is the boundary. Either we accept imprecise borders, or we use external sources for the precision and the verification. I think it is safe to say that OSM already does both in many cases.
5 Likes
Time and again, similar attempts to populate huge geographical features (timezones, bays, mountain chains, geographical regions, seas, …) open a question of boundaries of OpenStreetMap’s scope, which has never been definitely answered. Obviously, such huge features do not play well along with local features, due to tools’ and data model limitations (and generally, it’s hard to design a model of pretty much anything that would scale well across such a huge range of dimensions).
For the start, OpenStreetMap lacks a proper layer model which could help separate global from local features. If we could go back and design the model from scratch, boundary would be a separate layer/namespace implemented in different database tables, which could only be queried from a joint API but otherwise completely separated. For most use cases (including routing, our original purpose), one does not need boundaries along with local geographic features such as highways and waterways.
But that’s water under the bridge… 
Unless we reach a clearcut specification about our scope, implemented by majority vote if it must be, there will always be frictions like this. I’m not even saying that we should do that, but then we will have to accept that it’s a byproduct of an anarchic-by-design model that we have (and that has been a success story for the most part).
2 Likes
I believe layers would probably create more problems than they solve. If there are things that can be kept completely separate because they do not interact with any of the other data, and these could be just as well be kept in a different project, and could also be filtered in the current model as e.g. Josm allows you to do, which would seem just the exact same as a different “layer”.
OTOH, it is a problem that extraordinary large objects can only be recorded as the sum or composite of many relatively small objects.
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