[tz] Time zone selection

[Matt Johnson]

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

-Matt
________________________________________
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.