[tz] Time zone selection
mj1856 at hotmail.com
Fri Apr 22 16:04:00 UTC 2016
I don't really like the zone-now.tab idea, because it would just reflect things as of the date of the tzdata release, which is somewhat arbitrary with respect to the scenario.
What would really be useful, at least for me, would be if the tzdata had a separate file that recorded the zone splits. It would include the original time zone, the new time zone, and the timestamp of when the split occurred.
So using the last few Russian splits as examples:
# ZONE SPLIT_FROM TIMESTAMP
Asia/Tomsk Asia/Novosibirsk 2016-05-29T02:00+06:00
Europe/Astrakhan Europe/Volgograd 2016-03-27T02:00+02:00
Europe/Ulyanovsk Europe/Moscow 2016-03-27T02:00+02:00
Asia/Barnaul Asia/Omsk 2016-03-27T02:00+06:00
This wouldn't be too difficult to derive, as most of the information is already in the news announcements
From: Paul Eggert <eggert at cs.ucla.edu>
Sent: Monday, April 18, 2016 9:52 AM
To: Matt Johnson; Time Zone Mailing List
Subject: Re: [tz] Time zone selection
On 04/18/2016 09:04 AM, Matt Johnson wrote:
> To my knowledge, there is no project that maintains localized
> translations for comments in zone.tab. Not even CLDR.
I don't know of any either. Perhaps CLDR could take this on too?
> I've computed a "threshold date" for each zone, where the zones are
> identical from the threshold date forward. That date can be set by the
> developer of the application to limit the subset of zones to choose
> from without imposing too much opinion. I'm curious if anyone else has
> explored this space before, or used similar techniques?
I did something along those lines, but gave up on it as being too hard
to automate well. For example, if the threshold is 2001-01-01 00:00:00
UTC, then we should merge America/Boise, America/Denver,
America/Edmonton, and America/Yellowknife. How does the automated
procedure choose the ID of the merged region? It should be
America/Denver, as that has the greatest population, but how is the
population recorded and what happens as population changes? Furthermore,
how does the automated procedure derive the comment for the merged
region? And how would CLDR translate this automatically-derived comment?
For this reason I'm somewhat inclined to add one more hand-maintained
table, zone-now.tab, which is like zone-1970.tab except using a cutoff
of "now" (a deliberatly moving target) instead of a cutoff of 1970. That
should be good enough for applications that don't need historical time
stamps, and will be easier to automate and CLDRize.
More information about the tz