[tz] Time zone selection

[Matt Johnson]

Well, "historical" as of when?  Let's assume we had zone-now.tab already and follow Asia/Tomsk as an example.  It would show up in the list in 2016d as it was added.  Let's say 2016e doesn't come out until June, at that point it would be removed from the list because it's only historical since there's another Russian zone with the same fixed offset.  So how useful is this really?

Let me amend my previous suggestion, as I had it backwards.  For purposes of time zone selection, it's not the split date that is important, but rather the "merge date".  That is, "from X date forward, zone A is identical to zone B".  Then each individual developer can decided what the earliest date is that they care about, and omit zones that are identical since that date.

So for example:

# ZONE    SAME_AS    FROM_TIMESTAMP
Asia/Tomsk    Asia/Krasnoyarsk    2016-05-29T03:00+07:00
Europe/Astrakhan    Europe/Samara    2016-03-27T03:00+03:00
Europe/Ulyanovsk    Europe/Samara    2016-03-27T03:00+03:00
Asia/Barnaul    Asia/Novosibirsk    2016-03-27T03:00+07:00

We could still consider tracking the split date as well, but that would be more useful for working with historical data (dates before the split date).

________________________________________
From: tz-bounces at iana.org <tz-bounces at iana.org> on behalf of Random832 <random832 at fastmail.com>
Sent: Friday, April 22, 2016 9:13 AM
To: tz at iana.org
Subject: Re: [tz] Time zone selection

On Fri, Apr 22, 2016, at 12:04, Matt Johnson wrote:
> 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.

How is that different from the fact that literally everything else in
the release reflects things as of the date of the release?

The point is that the zones that are "merged" are _obsolete_, and
therefore no-one who newly selects their timezone after that date
"should" be using them anymore if they don't need historical timestamps.