Time Zone Boundaries

General talk
181

Those are only combined inside of that database. They point to the same rule set. Geographically, and for end users who configure their server or other computer properly, something like Europe/Brussels never means ‘an area which includes the Netherlands’.

Again, the fact that something like Asia/Ho_Chi_Minh points to the same rule set as Asia/Bangkok does not mean Asia/Bangkok is bigger than Thailand and suddenly includes Vietnam; not from a geographical perspective for end users. Configuring a server in Thailand? Choose Asia/Bangkok. Moving the server rack to Vietnam? Change it to Asia/Ho_Chi_Minh. Forgot to do that? No problem, they both point to the same rule set, as long as the Vietnamese don’t unilaterally change their laws regarding time keeping.

So no, in a geographical sense, Asia/Ho_Chi_Minh is not part of Asia/Bangkok. You are looking at the innards of a very complex database, where those identifiers are grouped together for reasons internal to tz database. Seeing that as the canonical truth you get people creating a relation covering the Netherlands, Belgium, and Luxemburg and calling it Europe/Brussels, and that is just silly.

I can configure my computer to use Europe/Brussels and it will still end up using CET/CEST, but if The Hague decides that we stop observing daylight saving time, but Brussels keeps on doing it, my computer will be off by an hour part of the year. Hence, Europe/Amsterdam, which would then point to the updated rule set in a new release of tz database. And trust me, if that happens, Europe/Amsterdam would be recreated as a separate rule set in tz database.

The IANA identifiers are there so you can be sure that as long as you are considering the area that identifier covers, you will have the correct time. Of course, what that area is changes (Asia/Ho_Chi_Minh now stands for reunified Vietnam, not just South Vietnam), but that is not our problem since we only care about now, and the now is pretty much well-known and obvious — including when it changes.

It is totally possible to map areas which correspond to time offsets, standard timezones, and IANA identifiers. How and if is a different matter.

What is the point of that? That would mean that from all IANA identifers which point to CET/CEST you only record Europe/Paris (no Amsterdam, Brussels, Berlin, etc.). Why even bother with the IANA identifiers then? You would end up with what is literally the whole of the countries observing CET/CEST tagged as Europe/Paris. Not even Napoleon managed to extend the French empire that far.

Agreed. Makes sense and clears up a lot of confusion.

Are you suggesting timezone:posix=* for things like CET? Why? :confused: That’s the wrong way around. POSIX may codify those identifiers, but is not the source of them (laws and conventions are). For a key name it is weird. Use something along the lines of ‘standard time’; timezone:standard_time=CET for instance, coupled with timezone:daylight_savings=CEST, as suggested by @aighes.

182

It’s a great question. On the one hand, I agree with you that zonenow.tab is an abstraction that most people don’t follow, even if it might be purer from a “verifiability” standpoint. On the other hand, I also agree with you that zone1970.tab makes plenty of distinctions that don’t matter in practice for the singular use case of setting a computer’s clock. The problem is that we’re thinking about this problem far harder than anyone else. Other applications and standards just say “use tz”, and if a zone1970.tab entry falls out of the hopper, no problem. They use one of these identifiers and clients are expected to know what it means. OSM is how they know what it means. It doesn’t have to be that way, though.

The :posix would merely indicate the format, similar to how we distinguish ISO3166-1:alpha2=* from ISO3166-1:alpha3=*. The POSIX format combines a bunch of things, enough to reconstruct one of the rulesets you’re referring to. The “CET” abbreviation comes along for the ride but isn’t the key’s main purpose. If we want our own syntax for recording timekeeping practices, then multiple keys would be fine, but just the two acronyms alone are quite ambiguous, so once again an external database would need to correlate it to the actual timekeeping rules.

Anyways, I figured we would’ve taken inspiration from opening_hours=* syntax by now. Let’s make OSM’s time zone coverage as difficult to use as possible. :upside_down_face:

  • IANA: America/Chicago
  • POSIX: CST6CDT,M3.2.0/2:00:00,M11.1.0/2:00:00
  • OSM: timezone=UTC-06:00 "CST"; UTC-05:00 @ (Mar Su[2] 02:00 - Nov Su[1] 02:00) "CDT"
183

Maybe that’s the “misunderstanding”. We are not mapping any IANA zones. We map boundaries (or other verifiable objects) and then referencing those to a more or less suitable description on IANA side.

I would agree with @trial that zone1970.tab is out of scope for OSM and with @JeroenHoek that if we refer to something, zone.tab should be the one to have in timezone:IANA.

zonenow.tab seems to be identical to the “actual” timezones, like ET or CET. I don’t see a point using Europe/Paris in OSM if “CET/CEST” is used commonly by the folks out there.

1 Like
184

That seems to be too complex and as well I figured, those short names are not unique. Like your CST is used for Central Standard Time and China Standard Time. :cry:

185

In a quest to avoid identifiers that have anything to do with history, we’d prefer identifiers from a file that’s deprecated and only provided for historical reference? This discussion sure is head-spinning.

No, the zonenow.tab zones aren’t necessarily identical to colloquial standard time names. For example, the file contains America/Mexico_City and America/Chicago, both of which are referred to as “CST” for part of the year, and both America/Denver and America/Phoenix, which are known as “MST” for part of the year.

(In case there’s any confusion on this point, the tz database doesn’t strive to contain an identifier per time zone per country. There are parts of Canada that only share an IANA time zone with parts of the U.S., lacking any identifier that names a Canadian city.)

“CST” is what people call the standard time observed in the middle part of the U.S. How is that different than the “CET” that you tagged on Germany? Anyways, my opening hours–inspired example was somewhat tongue-in-cheek. No one would want to make a parser for that. Even if we did agree to such a syntax, the "comments" would not be unique.

186

Aren’t you focussed way too heavily on those files in the tz database project? Zoom out a little and see how these IANA identifiers are used on a daily basis.

Someone coding an application in Java where only one timezone is used and some form of formatting for the end user is required might do this:

// Hard-coded, we only use this one.
ZoneId zoneId = ZoneId.of("Europe/Amsterdam");
ZonedDateTime date = ZonedDateTime.now(zoneId);
DateTimeFormatter dtf = DateTimeFormatter.ofLocalizedDateTime(FormatStyle.MEDIUM);
System.out.println(dtf.format(date));

The result was 15 Jan 2026, 08:52:33, which is my local time (CET) here in the Netherlands at the time of writing this.

(In case of more timezones they could store the IANA identifier in the user profile and get it from the database or the call environment.)

Java (and basically every other tech stack out there) hooks directly into tz database. In the case of Java it is included in the JDK.

Or consider how to configure the timezone on a Linux device. Usually if you install the OS you get asked for your location, and if you input any place name it can find, the corresponding IANA identifier is picked automatically (so I can pick ‘Leeuwarden’ and get Europe/Amsterdam automatically).

If you follow these instructions and configure it yourself, you’ll see that the OS has a whole directory filled with IANA timezone identifers in /usr/share/zoneinfo (note that Asia/Hanoi is missing from there being deprecated, but Asia/Ho_Chi_Minh is included, as expected), and that /etc/localtime points to one of those files.

Running timedatectl on my computer gives:

               Local time: do 2026-01-15 08:55:23 CET
           Universal time: do 2026-01-15 07:55:23 UTC
                 RTC time: do 2026-01-15 07:55:24
                Time zone: Europe/Amsterdam (CET, +0100)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Not Europe/Paris or Europe/Brussels. In the summer that Time zone: line will read Europe/Amsterdam (CEST, +0200).

Those files in the tz database repo are source files for building the actual database which gets included in every software stack out there. Don’t focus too much on interpreting them literally, that’s not their purpose. As an end user all you need to know is which IANA identifier applies to your area. That is the thing which is mapped now by using timezone=*. There is no ambiguity there, and in no way does Europe/Paris ever mean more than France métropolitaine for our purposes.

187

For France, the law is defining the legal time base (UTC) then the time in different places (UTC+1 and UTC+2 for DST for the mainland). FRENCH LEGAL TIME (using legal wording) doesn’t say anything about Europe/Paris or CET.
Ordinary people speak about heure d’hiver/heure d’été (winter time, summer time), GMT+1, GMT+2, UTC+1, UTC+2 or TUC, on computer they’ll use Europe/Paris).
CET/CEST in not used in France. I discovered the French abbreviation HNEC/HAEC while looking on Wikipedia for this thread.

While working with French and other people around the globe, I was updating my profile to display the local time with shortcuts used in US (CET, CEST…) and with UTC offsets.

Note the discrepance between the geolocation of France (Western Europe) and the name of the time zone (Central Europe) - even if the name according to @aighes is due to the 3 time zones used in EU, matching the German denomination.

188

This is normal If you live in a country with just one timezone¹ shared with all of your neighbours. Most French never deal with timezones and just grudgingly change their clocks twice a year for DST. IT professionals in France all know about CET/CEST and HNEC/HAEC of course. In French, everything is localised to a very high degree, and in that it differs significantly from its neighbouring countries; that is why you will find little general knowledge of the acronym CET there, whilst a much larger percentage of Dutch do (and hardly any of them use MET, the Dutch acronym).

Most French do know that they are in a timezone which conveniently spans much of Europe and all of their land-linked neighbours, and I’m sure most realise that the whole of that zone is not called Europe/Paris either. Whatever they call it, it is that CET/CEST thingy.

But even in the Netherlands most people remain blissfully untroubled by timezones, and just deal with wintertijd and zomertijd. Occasionally augmented by the common knowledge that Great Britain is an hour behind the times when there’s some program on the BBC to watch (for the old folk who still view linear live television channels).

All that doesn’t mean these timezones don’t exist. :slight_smile:

1: Yes, France d’outre-mer is a thing. Most French rarely deal with that, just like most Dutch rarely deal with the Caribbean municipalities and vestigial countries of the kingdom. Those who do are quite aware of the timezones involved.

1 Like
189

This isn’t a use case for time zone geometries, is it? Most clients of timezone-boundary-builder’s Java port seem to convert from UTC to the local time or vice versa based on a given coordinate pair. The whole point is to internationalize or localize the timestamp without hard-coding the local time zone.

Yes, Asia/Hanoi is officially deprecated in favor of Asia/Bangkok with a note saying the latter applies to “north Vietnam”. It’s separated from Asia/Ho_Chi_Minh by a historical boundary. You’re right that most people setting their computer clocks in the north would choose Asia/Ho_Chi_Minh anyways. It makes no difference for timestamps going forward, and I suppose some would consider it a display of patriotism. However, this is the most manual use case for tz data. I’ve been trying to make the point that the geometries are actually more relevant to automated use cases where the user doesn’t indicate their preference beyond “whatever is locally appropriate”.

All I know is that, if we introduce tags based on systematically going through a collection of identifiers that literally says “deprecated” at the top, we don’t have much of a leg to stand on the next time someone revives this thread to complain that we’re geeking out about historical timekeeping again.

To reiterate, my primary goal is to carve out space for real-world literal time zone boundaries in several countries, which don’t necessarily line up with actual time observance. I hope I’ve satisfied everyone’s concerns that these are a good fit for OSM. Unfortunately, so far, these boundaries have been preempted by modeling IANA time zones as boundary relations (from whichever file). By design, those abstractions are “alien” to a nontechnical person and in my opinion harder to justify in OSM in the long run, however we name them.

Even so, I recognize that a nontrivial amount of consumer and scientific infrastructure currently depends on OSM’s boundary=timezone relations and timezone=* tags, regardless of our intended project scope. I strongly suspect that the Wikidata–OHM combination can track these geometries accurately and durably, with more nuance and less drama than anything we shoehorn into OSM. Successfully migrating these projects to Wikidata and OHM will require patience, cooperation, and mental gymnastics, not dismissiveness about these external projects.

Local time observance rules (UTC offsets, DST start and end dates, and the colloquial names for these rules) have also been preempted by IANA time zones to some extent. If we accept the real boundaries as coherent boundary relations, they could coexist with time observance rules as tags, for thematic mapping and occasional nerdsniping. Personally, I’m open to any syntax for this information as long as it’s somewhat machine readable and doesn’t preempt the real boundaries. (It would be a lot easier than solving the problem of how to resolve PH and SH in opening hours syntax.) Meanwhile, for practical automated use cases, Wikidata would all but eliminate the need for IANA time zones or their names in OSM.

1 Like
190

Just wanted to point out, that CST is also what folks in China call their timezone. So using CST as a value in OSM is ambiguous.

191

What did you mean by “CET” and “CEST” when you tagged those abbreviations on the Germany boundary relation? Did you intend them as conventional English abbreviations or POSIX identifiers, to be used literally like operator=*? Or as bespoke identifiers unique to OSM, like we sometimes put in network=*? I assumed the former, but if it’s the latter, then such conflicts are inevitable unless spell the words out or namespace the values by country code.

192

I intended the former and thought about CET, ET, CT, MT, PT,… which would have avoided the conflict with CST. Though it seems there are more conflicts.

Thinking about your opening_hours idea… maybe tagging timezone=Eastern Time in combination with timezone:daylight_saving=+1 @ (Mar Su[2] 02:00 - Nov Su[1]) or timezone:daylight_saving=none is a good compromise regarding complexity and readability?

193

Of course, spelling it out doesn’t guarantee uniqueness either. The Mexican “Pacific Time” corresponds to the U.S. “Mountain Time”.

If this timezone=* is freeform text, then it’s only a matter of time before someone gets the idea to change “Central European Time” to the less Anglocentric “mitteleuropäische Zeit”, someone else gets the idea to tag timezone:fr=*, and a third mapper comes up with timezone:wikidata=Q25989. If a developer is going through all the trouble to parse timezone:conditional=* based on the notoriously difficult opening hours syntax, then they might as well use the numeric utc=* for standard time instead of having to maintain a lookup table of human-readable time zone names.

194

Trying to think the other way around.
Timezones can be relations, with name=Central European Time/Central European Summer Time, name:en, name:fr, with short_name=CET/CEST, wikidata,… and including some sub areas(*) like mainland France, Germany, Belgium, that way you have more choices and less conflicts.

(*) for US possibly also sub areas (being states like DC or non administrative relations)?

195

That would be a category of the administrative areas that observe a common time. Central European Time is associated with a geography for thematic purposes but it isn’t a kind of place like a country. Tags on other features should be adequate for the most part. This is the same approach we take for the Francophonie or the right-hand driving world and I don’t see much reason to depart from it.

I even think the U.S. should not have a Central Standard Time relation either. What I’ve been campaigning for is a boundary relation for the Central Time Zone, which is not the sum of places that observe Central Standard Time. For example, Fort Pierre, South Dakota, lies to the west of the Mountain Time Zone signs but observes Central Standard Time anyways. Certain railroads are legally required to observe Central Standard Time outside of the Central Time Zone.[1] The Central Time Zone boundary would appear on maps, but software that converts timestamps to or from local time would not rely on this boundary.

I’m still unclear on what proponents of standard time tagging want this information to be used for. If we simply care about recording the fact of people calling their time a certain name, then naming collisions don’t matter at all. On the other hand, if we care about data consumers being able to infer the current UTC offset for a given place, then the names aren’t as useful as UTC offsets with start and end dates, though it sure would be easier to just use Wikidata.

  1. Technically the rail carrier exemptions would not apply to other companies using the same tracks. However, in practice, other companies like Amtrak surely follow the same times. Otherwise, that would be a disaster waiting to happen. It would literally defeat the original intended purpose of time zones. ↩︎

196

By the way, the existing conditional restriction syntax is inadequate for fully expressing all the daylight saving time rules in a machine readable manner. For example, Morocco’s DST dates are tied to Ramadan and the Islamic calendar, but the opening hours syntax lacks support for alternative calendars, particularly lunar calendars. This isn’t a problem if Morocco is tagged Africa/Casablanca, which is tied to these rules, or if data consumers use Wikidata to associate the country with Africa/Casablanca, relying on OSM for the boundary geometry only.

197

After reading a bit more of the documentation of the tz database, I agree - I don’t see the point of tagging something like timezone:standard_time=CET timezone:daylight_saving=CEST on Germany. This data still doesn’t tell you when the transitions between summer and winter time happen. For example, the US switches to summer time at a different time from the UK and EU. You can try to fit this into an opening hours-like syntax, but it will get incredibly complicated with edge cases and exceptions. This information is probably out of scope for OSM, so you’d need to create an external database to store this information.

The IANA tz database solves exactly this problem.

  • If all we care about is time stamps in the future (e.g. so that CoMaps or OSMAnd can show me if a restaurant across the border is open right now), then it solves it with the file zonenow.tab. In this file, the area covered by CET in the winter and CEST in the summer is called Europe/Paris. Ignore that it says “Paris”. This has nothing to do with Napoleon’s ambitions. It is just a string that the maintainers of the database have decided on, for reasons unrelated to OSM, to uniquely identify this time zone. It might as well be called TZ456. From that perspective, Europe/Paris is an area that includes the Netherlands, and Europe/Berlin and Europe/Amsterdam are mere aliases.
  • If we want OSM data to remain useful for time stamps in the past (important for scientific and data analysis applications e.g. what time was it in Houston, Texas on 20 July 1969, 20:17:39 UTC?), then we have to decide between zone.tab and zone1970.tab. In both of these files, Europe/Paris and Europe/Amsterdam are separate zones, that don’t point to the same ruleset.

In the current OSM data, timezone= seems to mostly be a mix of the zones from zone.tab and the ones from zone1970.tab. For example, Iceland has timezone=Europe/Reykjavik, this is correct according to zone.tab when according to zone1970.tab it’s in Africa/Abidjan. But Asia/Dubai follows zone1970.tab not zone.tab: it includes Oman, the Seychelles and others, not just the UAE.

The advantage of looking at the source files is that they solve the verifiability problem. They contain relatively clear definitions like:

zone1970.tab
BE,LU,NL +5050+00420 Europe/Brussels

or

zone.tab
BE +5050+00420 Europe/Brussels

These tell us which admin boundaries should get the timezone=Europe/Brussels tag (or, where in rare cases a relation may be needed).

198

Officially deprecated or not, the zones in zone.tab seem to have a few advantages

  • they map the most neatly to existing admin boundaries: the file follows a rule of “never more than one country per zone”, so for a lot of countries (but not for all) it takes the form Continent/Capital which you can put into the timezone= (or timezone:iana=) tag and you’re done
  • a lot of applications seem to be presenting these zones to users, so if I run timedatectl list-timezones on a Linux system, I am getting options like Europe/Amsterdam or Europe/Copenhagen, not just Paris and Brussels (as @JeroenHoek noted)
  • re-reading @EvanSiroky’s post further up, I think the zones in zone.tab are also the most useful for timezone-boundary-builder because they are the most granular - so you can assemble the other versions if you have them, but not the other way around:

We could also map multiple versions, we just put them in timezone:iana= and timezone:iana1970= (plus timezone:iana_now= if we want to map those too).

1 Like
199

The only issue with them is, that they do not match the observed reality, like in the Europe/Berlin vs. Europe/Busingen case. Where the observed reality is, that whole Germany is within one time zone. So to make sense out of them, you need external sources.

Which is kind of what you disliked on using CET/CEST. Why you think an external dependency to tz-database is different?

If you want to have everything in OSM, we would need to go with UTC offset and opening_hours-like syntax for DST.

I suggest not to focus too much on how one OS displays your set timezone. As pointed out earlier, that’s different for each OS. A Garmin-Device displays it different than an UNIX, Windows, Android, Casio-watch, … I believe we do not want to have all of those in OSM. :wink:

200

I don’t dislike references to external databases. Quite the opposite: I was saying, if someone has already created it (= the tz database), then let’s not recreate it, but just link to it.

Linux happens to use it, but that’s not its only purpose.

Anyway, if people really want to tag standard_time=CET then I am not against it, I just won’t be doing it myself, because timezone:iana=Europe/Paris contains the same information plus a lot more.

2 Likes