[tz] Zone name policy

Matt Johnson mj1856 at live.com
Fri Dec 2 05:01:07 UTC 2016


> “I set my timezone to 4ccd94040a7d96dfb3a1a6b0e7db8d162e039515b09b73ec60fd7eb5bca3241 and the date shows as UTC what am I doing wrong?”

Every StackOverflow time zone question ever.



From: John Haxby<mailto:john.haxby at oracle.com>
Sent: Thursday, December 1, 2016 2:43 PM
To: Paul Eggert<mailto:eggert at cs.ucla.edu>
Cc: Time Zone Mailing List<mailto:tz at iana.org>; Maksym Besida<mailto:maks.besida at gmail.com>
Subject: Re: [tz] Zone name policy


On 1 Dec 2016, at 21:46, Paul Eggert <eggert at cs.ucla.edu<mailto:eggert at cs.ucla.edu>> wrote:

On 12/01/2016 01:30 PM, Guy Harris wrote:
It would have been nice if there had been some form of ID that we could have used for tzdb zones that*didn't* involve city names

How about SHA-256 checksums? Instead of "Europe/Kiev" the zone name would be "099d2adb7f9a187c25224cd49364de6d510d6e89924584c0b97d88d3f801e551", which would make users less likely to raise political objections. SHA3-512 is also a possibility, although SHA3 software isn't as mature and the names would be a bit long. (:-)

You’d have to have an interim version that kept both the existing names and the hash while the various distros and platforms convert from their current selector to a selector that uses the hash names.   You could be relatively draconian about this: provide the interim names for a little while and then leave it up to the long-lived distros and platforms to put the existing names back because that’s what the platforms and application software demands.   For the sake of consistency among all those long-lived platforms (we’re talking at least decade before the various LTS’s stop providing tzdata updates) then it would be best if tzdata maintains the mapping table.

It would probably be best to coordinate the initial change with CLDR so that they can maintain both the new (preferred) hashes and the old names during the transition decade.   There would probably be a range of lucrative consulting projects as well to help people move from the old naming scheme to the new naming scheme and a selector that’s as good as the Apple one.

I suspect that at some time during the transition decade that it will become apparent that the old names will need to be accessible one way or another for debugging and support purposes.   (A user claims that 099d2…1e551 is the wrong timezone for their part of the world but investigation shows that this is the old Europe/Kiev timezone name and they live in Whitby.  Yorkshire.  England.)  It would probably be a good idea to embed the old name in the binary file so that it can be easily retrieved.

In fact this then gives a way for the diehards to revert to the old names.   Unfortunately the diehard systems will then have Europe/Kiev instead of Europe/Kyiv so unfortunately we’ll still get complaints, albeit from a smaller group of people.

Introducing a new timezone will require some coordination across the board.   Out friend in Whitby (who runs on a different time to everyone else) will be using 4ccd94040a7d96dfb3a1a6b0e7db8d162e039515b09b73ec60fd7eb5bca3241b which will need to be added to CLDR at the same time it is invented so that the distro can update tzdata and the corresponding translation at the same time.

I’m sure all that is doable the transition will be complete in a couple of decades and there will be hardly anyone using the old names and complaints about the embedded English names will be few and far between, or at least very much less than “I set my timezone to 4ccd94040a7d96dfb3a1a6b0e7db8d162e039515b09b73ec60fd7eb5bca3241 and the date shows as UTC what am I doing wrong?”


On the other hand we could keep the status quo and continue to persuade the distros to use CLDR and provide a decent selector.

I have a sneaking suspicious Paul wasn’t being entirely serious.   If we could go back 30 years and use abstract names and build in internationalization from the outset then maybe it would have worked and CLDR wouldn’t need to deal with timezone names.   With 20/20 hindsight we could probably design a system that would have worked in 1986 but I doubt it could have been designed then  (Digital’s IPG was quite a new group and the stuff they were doing then was cutting edge.)

jch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20161202/4848782b/attachment-0001.html>


More information about the tz mailing list