[tz] Time zone selection
mj1856 at hotmail.com
Fri Apr 22 17:42:56 UTC 2016
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.
More information about the tz