[tz] tzdb timezone names/identifiers and links (was: Add new timezone for Hanoi Capital, Vietnam)

Guy Harris guy at alum.mit.edu
Tue Feb 19 20:27:15 UTC 2019


On Feb 19, 2019, at 11:14 AM, Hans-Joerg Happel <happel at audriga.com> wrote:
> 
> Dear Paul,
> 
> thanks for the elaboration - further comments inline
> On 19.02.19 17:34, Paul Eggert wrote:
>> Hans-Joerg Happel wrote: 
>>> So any information on the rationale for the above-quoted rule is 
>>> appreciated. 
>> 
>> When I introduced locations as tzdb identifiers long ago, I naively put in one Zone or Link per country. Some users got accustomed to the idea that Zone and/or Link status was akin to political recognition of countries or their boundaries (is Kosovo a country? is Jerusalem part of Palestine? that sort of thing) and so I eventually realized my mistake: the identifiers are now supposed to be single locations, decoupled from countries or national regions. 
>> 
>> At one point I attempted to simplify the database by coalescing regions that crossed country boundaries, since there's no longer any need to conflate the two. Unfortunately this flustered some users who thought this meant disrepect to particular countries (which was not the intent). After some back and forth we ended up with the current wording, which I'm not happy with, as the current rules are still too political and we still end up with "There should be an entry for Hanoi/Beijing/etc.!" discussions. 
>> 
>> If this continues to be a sore spot, I'm inclined to adjust the rules so that there need not at least one Link or Zone per country. This should help simplify future maintenance if, say, the US splits into multiple countries (and stuff like that does happen). 
> I'd see two different kinds of "maintenance" here:
> 
> * Maintenance of tzdb (which you are referring to)
> * Maintenance of systems/data by people using tzdb (directly or indirectly)
> 
> So in your example - if say, Washington (the federal state) would become a separate country, you argue to keep maintenance of tzdb low by sticking to "America/Los_Angeles", whereas one could argue for a link from "America/Seattle" (or the like) according to the current ISO 3166-1 rule in [1].
> On the other hand, if Washington users could make use of such an "America/Seattle" alias, that could reduce maintenance effort in the event of of the new country of Washington deciding to deviate from "America/Los_Angeles" rules (which, as you say is stuff that will happen one or the other way).

Unfortunately, the tzdb maintainers *and* the tzdb users can't necessarily anticipate what additional zones might be created.  America/Los_Angeles may, in the future, not be appropriate for Washington - or Oregon, even *without* the US dividing itself up:

	https://www.ballotpedia.org/California_Proposition_7,_Permanent_Daylight_Saving_Time_Measure_(2018)

but you might not have to go back too far to find a time when few people would have predicted that.

So I don't know how much prediction of future time changes we can do in order to decide what tzdb regions there should be.

> My assumption (also in the US/Washington case above) is, that it is (in most cases) countries which do cast decisions about time zone rules.

It is, in most cases, governments that make those decisions; they may be national governments or regional governments within nations or a combination of the two.

> Therefore, both Vietnam and Thailand seem to be free to change time zone rules at any time soon.

Yes (and to do so without much notice, as governments are sadly all too wont to do, provoking the usual scramble on the part of the tzdb maintainers and vendors shipping the tzdb).

> Assuming two databases, one with "Vietnamese data" on an office server in Hanoi, one with "Thai data" on an office server in Bangkok, both databases would currently use "Asia/Bangkok" as an identifier.
> 
> So in case the Thai government decides to change time zone rules for Thailand (and Vietnam would not follow), if I am not wrong, this would most probably require tzdb to introduce an "Asia/Hanoi" identifier to accommodate for this new situation.

Yes.

> However, people maintaining the server with "Vietnamese data" might then need to convert that data from using "Asia/Bangkok" to "Asia/Hanoi" (my example may sound a little simple or arbitrary, but I also want to understand if you share the idea that this may be a point).

Yes.

Maybe this is *another* case where "some applications "misuse" tzdb identifiers" and where it might "be better to solve this on a more general level such as geo-location<=>timezone mappings", e.g. a meeting date shouldn't be tagged with {date/time, tzdb identifier} but with {date/time, geographic coordinates}.  I'm not sure whether the geographic coordinates of the meeting location are more or less likely to change than the time zone rules of that location, but, with the geographic coordinates changing, that's probably a big enough change ("we've decided to move the meeting from Los Angeles, CA to Vancouver, BC") that the system can cope with it.

It is, however, also a case where a "don't have tzdb regions that cover more than one country unless there's a good reason to believe that all countries within the region will coordinate their time zone offsets and summer time rules" rule might be a 90% solution.


More information about the tz mailing list