I don’t understand the logic that, if we can’t somehow accommodate proprietary or legacy systems, we can’t accommodate modern open standards either. Microsoft has their own incompatible schemes for country codes, language codes, and more, but we ignore them in favor of the current ISO standards for these things. The O in our name stands for Open, after all.
Reverse geocoding is the main reason an application or service would need time zone geometries. If a field sensor provides a coordinate pair and a timestamp from six months ago, the geometries allow a scientist to reliably convert the timestamp from UTC to local time or vice versa without already knowing which local time applies to the timestamp. If my computer wants to set the system clock automatically, it can geocode my current location among time zone geometries without asking me which country I’m in. The geometries don’t have to come from raw OSM data; they can be derived from OSM and OHM data based on rules and heuristics stored elsewhere.
For these use cases, a time zone name is neither the initial input nor the final output. It’s an intermediate identifier that enables the application or service to look up the specific time rules unambiguously. The end user isn’t supposed to see the zone name, but that doesn’t make it somehow less important than the human-readable display name. By analogy, think of all the times we’ve told people not to map local legislation because data consumers can look up the relevant boundary relation ID or country code in an external database. The zone name serves the same purpose for a different kind of geography. It absolves us of the need to model specific time rules, which will be a neverending headache.
Regardless, as you noted, what we have in the database is a mishmash of incomplete coverage of different layers, all using the same tags on boundary relations. I don’t think we can realistically resolve this using the existing approach:
zone.tab and zone1970.tab rely to some extent on historical administrative boundaries (albeit not to the same extent as backzone). If we aim for complete coverage of either layer, we’ll probably need to map more historical boundaries in OSM. That would apparently annoy OSM mappers, and it would also be unfair to OHM.
tz intentionally ignores official time zone boundaries in favor of actual time observance. To do justice to the IANA time zones, we’d need to shift the boundaries to the other side of numerous small towns. The more we aim for accurate coverage of tz, the further we’ll get from representing designated boundaries that are obviously in scope for OSM. Governments would complain that we’re misrepresenting the boundaries, and they’d be right for a change.
What if we freeze our current coverage of boundary=timezone relations while we use them to clean up Wikidata? Once we vet the time zone statements on Wikidata, timezone-boundary-builder can confidently migrate from the Overpass API to QLever, allowing us to delete the boundary=timezone relations without breaking data consumers. For IANA time zones that don’t correspond to OSM features – such as Germany minus Büsingen, Spain minus the Canary Islands, and Norway minus Bouvet Island – Wikidata would push the time zone statements down to multiple administrative subdivisions, like we were talking about doing in OSM.
This would leave boundary=timezone for a demarcated time zone boundary (which apparently doesn’t exist in Europe). Any local exception to the law can be tagged as timezone:iana=* on a boundary, POI, or railway, to say that it observes the time zone most similar to a certain IANA time zone – but not so that data consumers can build a comprehensive, coherent time zone geometry. time_name:xy=* would be available if anyone wants to tag the name of the locally observed time in the local languages. It would only be a note for reference, not for anything automated.
If you insist on seeing something like Europe/Brussels as anything but Belgium (like making it mean the BeNeLux), and Europe/Paris as anything but Metropolitan France (like making it mean essentially all nations observing CET/CEST) you are entering clown territory when applied to OpenStreetMap. The BeNeLux especially is not a timezone in any way in common parlance or use.
Deprecated in some of the files of tz database does not make an identifier like Europe/Amsterdam deprecated in the sense we are talking about here. Europe/Amsterdam is the conventional identifier to use if you want to point to the correct time keeping rules observed in the continental Netherlands. That’s what operating systems do, it is what developers dealing with timezones do, and it is what people document on sites like Wikipedia.
It is also what mappers already set out to do with the ill-named timezone=*. Only recently some people started adding things like the above.
So, going back to the Germany-sans-Büsingen boundary relation that reignited this thread, do you think we should restore that relation, or rely on equivalent tags on each of the Bundesländer? Büsingen has its own zone in zone.tab. Or do you think all of Germany should have the same timezone=Europe/Berlin since it’s good enough for a current timestamp in Büsingen, just as Europe/Brussels or Europe/Paris would be in any part of Germany?
The tz database insists that end users are never to see these identifiers anyways. Do you figure that some countries may end up with no timezone=* coverage because their residents haven’t gotten into the habit of speaking in terms of IANA time zone names?
If Europe/Busingen is in use, than I would expect there to be an area Europe/Berlin which excludes that exclave — personally I’d prefer a single relation over separate Bundesländer with that tag.
I mean, Europe/Berlin is ‘good enough’ for anyone in CET/CEST, including people in Madrid, but that is not the point of those identifiers. It is to have a stable identifier which points to the present and future time rules of the area it belongs to (and incidentally, also a good chunk of the modern past).
Anyone recording these IANA identifiers on OpenStreetMap is doing so for the benefit of people who use them or want to understand or visualize them. Developers, systems administrators, database administrators, and anyone who deals with low-level time rules primarily. They are not nearly as well-known as standard timezones, which is what most people deal with at some point, but they make sense just like ISO-3166-1 does.
Besides, end users are exposed to them in various places regardless of what tz database wants (if it wants anything):
Incidentally, note how the widget correctly states that Europe/RomeandEurope/Madrid are (part of) my current timezone.
The reliance on Wikidata. I don’t oppose people using that project (so great if timezone-boundary-builder can use it), but our data should be able to work without it.
I don’t think mappers should go and create boundary relations for IANA identifiers and standard time zones with thousands of boundary ways, but those can surely be mapped as relations of existing entities for the biggest part?
That’s why I tend to think we should have them in OSM. And probably Europe/Berlin for Germany [as currrently there in no difference], including its exclave, except if Germans prefer to keep them separated (but they seem to prefer to say MEZ i.e. CET).
So you are saying, each community should decide about how they want to call the timezone they are in? I don’t think that’s working out very well. I would assume you will also find communities, who reject to map timezones.
Either we follow a specific IANA classification. They define the span of the identifier, we reproduce them with the help of admin-boundaries (if possible). OSM should not define timezones. If we go for zone.tab, then Germany is split, regardless how Germans think. If we go for zonenow.tab the French took over central Europe. However, I don’t mind which one.
Or the best independent approach seems to be just mapping UTC-offsets to our admin-boundaries (if possible).
In general, if admin-boundaries are not usable, a boundary=timezone relation should be created.
No, just for cases like this where the exception (this exclave) is more obscure.
That would bring you back to a point where people will just (re-)add some tag with their local IANA identifier to their country under any tags you like. Facilitating these tags and providing guidelines to prevent people from creating relations for Europe/Berlin which include Norway seems the best way forward.
I would say the question “is the correct identifier for the timezone that Norway is in Europe/Oslo (following zone.tab) or Europe/Berlin (following zone1970.tab) or Europe/Paris (following zonenow.tab)” is quite separate from the question whether we should use tags on admin boundaries or relations: if we were to decide to follow zone1970.tab we could just put timezone=Europe/Berlin on Norway and timezone=Europe/Amsterdam on the Netherlands, without the need for a boundary relation.
Having said that I am fine with mapping zone.tab. From what I understand that’s not only more intuitive, but also the most useful to timezone-boundary-builder. The solution @Minh_Nguyen suggested also sounds fine to me.
No, I’m just asking for their input, to see if what is proposed makes sense to them. I’m fine with @osmuser63783’s answer.
In general, if admin-boundaries are not usable, a boundary=timezone relation should be created.
Sure. But then comes the how: an aggregation of “lower” admin-boundaries or a multipolygon. We can give a hint: try to keep the member count as low as possible. And if the tiny bits are spread from Alaska (not Greenland) to California (not Venezuela), it’s probably better to define some small (multi-)polygons and add them as subarea.
As far as I can tell, nothing uses boundary=timezone relations except through timezone-boundary-builder. Once Wikidata is cleaned up, timezone-boundary-builder would rely on Wikidata for choosing which OSM and OHM boundaries to merge together. So could Valhalla or any thematic map on Wikipedia. This would leave no reason to maintain the tz-based relations or even most of the timezone=* tags in OSM, other than for the sake of completeness. If the community wants to maintain a Europe/Berlin boundary relation that no one uses, for completeness, then sure, the data will “work” just fine.
Regrettably, until we can use boundary=timezone for the delineated boundaries instead of the virtual tz-based boundaries, a transportation map will have to look beyond OSM for the correct boundaries to depict on the map as boundary lines.
Your suggestion would superficially minimize the number of members, but it would be counterproductive in practice. Singling out this one set of boundaries for a non-boundary treatment would be as arbitrary and inexplicable as the alternate realities in that hidden text.
Last week, I offered myself up to science and ventured into the desert, wandering across the boundary between America/Los_Angeles and America/Phoenix several times. Thankfully I felt only a mild sensation of having to set my watch forward because it’s wintertime. Also, I kept seeing this other thing calling itself a time zone boundary, precisely where the laws and the maps said I would find it.
But then I kept going, crossing from America/Phoenix to America/Denver to a tiny enclave of America/Phoenix as a desert snowstorm set in. This time, the laws and the maps failed to warn me in advance that nothing would happen: the clocks stayed the same because it’s wintertime. As a mapper on the ground, I saw no evidence of a time zone boundary anywhere.
In both situations, what I witnessed on the ground was consistent with OHM. I hope someday the on-the-ground rule can coexist with the virtual time zones in OSM, whichever .tab file we decide on.
I would allow both variants, but nothing mixed and leave it to the local community. In fact as we learned it’s affecting mainly the US, where @Minh_Nguyen analyzed in general a boundary relation is easier than a super-relation. So if we want to enforce one specific type, it should be the boundary relation.
The designated time zone boundaries and IANA time zones are orthogonal concepts. It isn’t merely a technical choice of one database representation or another. So adjacent local communities would potentially be mapping different kinds of time zones. This could lead to confusion between mappers, even if data consumers migrate to a hybrid Wikidata/OSM solution. I think it would be better to reserve boundary=timezone relations for designated boundaries, relegating the IANA time zones to a tag on other kinds of features (which could be boundary=place features if boundary=administrative doesn’t suffice). Places like the U.S. should have both.
What’s the difference? First of all, although the designated time zone boundary is linked to a standard time, actual time observance differs in practice. If we were to accurately map the territories where people observe a given time, then in principle we’d have to depart from the designated boundaries almost everywhere, and it would be somewhat indefinite in places. Typically, when the designated boundary separates two towns, the smaller town observes two times simultaneously:
Most of daily life runs on commercial time, the same time observed by the larger town, such as shop opening hours, school and worship times, and bus schedules (which could be interesting to a public transit router).
Official business runs on official time, including bar and liquor store opening hours (hence “bar time”), voting hours, and conditional turn restrictions and access restrictions on highways (which is the reason Valhalla cares about these geometries).
Eventually, locals petition the federal government to change the legal to match commercial time, under the principle that most people are law-abiding. This starts the process all over again in the next town or county over. The legal change moves the signs but may or may not result in any change to the tz database. Sometimes they consider it to be merely a formal reflection of what the database already contains.
Secondly, the designated boundaries have nothing to do with daylight saving time. Two adjacent towns on the same side of the time zone boundary may observe different times during half of the year. The tz database handles this situation by assigning the towns to different time zones. This causes your Linux time zone picker to show geometries that look nothing like the time zones on well-produced time zone maps or transportation maps.
So goes the U.S.…
The situation in Australia is similar, with the extra wrinkle that some time zone boundaries only exist in practice and on signs but contradict the law. Mexican law incorporates whole states and municipalities into a given zone by reference, but there’s still a firm distinction between standard time and time zones.
And then there’s Canada. Individual town councils in British Columbia can decide whether or not to observe daylight saving time. One town goes further, putting itself in Pacific Time half the year and Mountain Time the other half of the year, moving the boundary signs twice a year. For that, tz lumps them in with America/Phoenix (albeit with a redirect on the Canadian side “for timezone historians”).
Brazil, Chile, Russia, and a few other countries’ mainlands also observe multiple standard times. They might have their own quirks.
You’re the Wikidata expert here so you’re better placed than most of us to judge if this is feasible!
Here are some things I wouldn’t be sure about
how stable this setup is - both technically (e.g. software support) and socially (e.g. someone accidentally breaking something)
community norms over at Wikidata (inclusion criteria, how likely someone is to put it up for deletion)
how much work the migration would be
whether we should consider OSM relation IDs for admin boundaries to be sufficiently stable to be used as external identifiers in this case; for example, if a country reorganises its internal admin boundaries, then an existing relation might get reused but now cover a different territory, or it might get deleted
how to represent discrepancies between zone.tab and zone1970.tab when they define the same zone differently
how accessible editing the data is (who is going to keep it up to date?)
whether this approach would address the issues raised by @Evan (Time Zone Boundaries - #8 by EvanSiroky) and whether he’s willing to modify timezone-boundary-builder to use it
It isn’t more or less stable, just different. Wikidata accepts public contributions just like OSM. Intentionally editing a located in time zone (P421) statement is much, much easier than intentionally refactoring a country-sized time zone boundary relation. But accidents involving these statements are much less likely than accidental boundary breakage in OSM. It’s also quite easy to put individual items on a watchlist or otherwise track changes to a SPARQL query.
Other geographical items such as metropolitan France (Q212429) have located in time zone (P421) statements that require the IANA time zone item to exist. The task here is to add more such statements, which would further protect the items from deletion.
There is some risk that a Wikipedian who doesn’t understand the tz database would unilaterally merge an IANA time zone item into a different item representing a conventional time zone or UTC offset. This is somewhat unlikely because of the IANA time zones’ relative obscurity, but we can protect them by removing tz zone names from the aliases of non-tz items. Another antidote is different from (P1889) statements.
Anyways, to put things in perspective, Wikidata has never deleted Europe/Berlin like we have.
This is unclear, mostly because OSM’s coverage is so heterogeneous. As far as I can tell, the boundary relations represent IANA time zones from both zone.tab and zone1970.tab, minus the ones that could be represented some other way. Wikidata would aim to be more comprehensive.
In principle, Wikidata would track the same administrative boundary changes. Even though Wikidata can link to OSM via OSM relation ID (P402) statements, the SPARQL queries I’ve been posting only rely on wikidata=* tags on OSM elements.
There are a couple ways to do this. For example, in the tz database, Europe/Paris has a single temporal definition in europe, even though it appears in zone.tab, zone1970.tab, and zonenow.tab with different spatial definitions:
Alternatively, Wikidata could split out three different Europe/Paris items, each one corresponding to an entry in one of the .tab files, so that metropolitan France (Q212429) would have to link to all three. This would be akin to mapping overlapping boundary=timezone relations in OSM.
The current model is probably more maintainable, especially if Wikidata ends up also covering backzone.
One other change I’d make on Wikidata is to stop giving the UTC offset statements preferred rank. That’s favoring one notion of timekeeping at the cost of more complex queries for IANA time zones, standard times, and designated time zones. Qualifiers do a better job of distinguishing between these concepts. If necessary, Wikidata could also split the property. Any drastic change will require a discussion with the Wikidata community, in case any existing data consumers (such as Wikipedia infoboxes) require the UTC offsets to be preferred.
This is why I’m not suggesting that we cut out OSM entirely. If Wikidata were to rely on, say, GeoJSON files uploaded to Wikimedia Commons, someone would need to keep those GeoJSON files up to date as administrative boundaries shift. I’m only suggesting Wikidata as an extra level of indirection. We should continue to rely on OSM (and OHM) to track the spatial extent of the individual administrative areas that comprise IANA time zones.
As far as I can tell, only a handful of mappers are keeping OSM’s time zone coverage current. More specifically, their updates mainly reflect changes to the tz database, though sometimes they benefit our coverage of administrative boundaries too. I have to imagine that they’d find it easier to update a handful of symbolic references in Wikidata than to wrangle huge boundaries in OSM, only to face scrutiny in a forum megathread afterward. Who knows, we might even be able to convince the tz database’s contributors to update Wikidata in parallel.
Incidentally, this might also be a partial solution to the problem of how to maintain open flight information region data.
Evan was comparing the status quo to the prospect of dissolving timezone=* tags onto more local administrative boundary relations in OSM and relying on those tags instead. I agree with him that such a representation verges on the absurd for anything that ultimately requires a coherent geometry. I similarly criticized this suggestion in the context of the U.S. designated time zone boundaries. The circumstances differ but the challenges are similar.
In all fairness, nothing is easier for timezone-boundary-builder than the status quo. After all, OSM’s coverage is more or less mature. But migrating the heuristics to Wikidata would enable the project to cover backzone and also hedge against future crusades against time zones in OSM. Evan and I are also on the same page about the tz database having a unique view of history that doesn’t fit OHM much better than OSM. That’s why I’m not proposing that timezone-boundary-builder “just” use OHM boundaries.
It’s better to think of my proposal as replacing timezone-boundary-builder’s use of the Overpass API with QLever, and copying any timezone=* tags that this community would support over to Wikidata. From that point onward, what OSM does regarding time zones becomes an internal matter for OSM. I left some implementation notes to this effect in a feature request on GitHub, along with a summary of this discussion:
The world keeps conspiring to make my forum posts obsolete. Most of British Columbia is adopting Creston Time. Unless I’ve made an off-by-one error, Creston would now match the new “Pacific Time” year-round except for calling it “Mountain Time” half the year. Maybe they’ll stop shuffling the boundary signs around twice a year.
Most of the province will be Pacific Time (PT) which is permanently UTC-7.
The northeast will continue to observe Mountain Standard Time (MST) which is also UTC-7[1] and is in alignment with the Yukon. The exception to this is Fort Ware which will switch from MST to PT.
There is a second area in the southeast where Creston is that doing the same as the northeast. This doesn’t extend to the Alberta border.
The southeast touching the Alberta border will continue to switch between MST and mountain daylight time (MDT).
In addition
Most of BC is switching from GMT offsets to UTC offsets
Vancouver may no longer prescribe a different schedule for when it is GMT-7
Provincial elections are held in PT throughout the province
local governments (other than vancouver?) can choose the time they want to observe
In practice there are no differences for everyday use, it’s just a modernization. They are defined differently in ways that matter for leap seconds and similar stuff. Anyone who cares about that stuff won’t be using local timezones in the first place.
