[tz] TZDB use cases
eggert at cs.ucla.edu
Sat Oct 2 02:24:22 UTC 2021
On 9/29/21 2:57 PM, Stephen Colebourne via tz wrote:
> * An abstract region should theoretically have an ID separate to the
> IDs of the cities/countries in the region
Yes, others have proposed this, notably Russ Allbery in
<https://mm.icann.org/pipermail/tz/2021-September/030518.html>. It's not
clear, though, whether merely adding this level of indirection would be
worth the cost. It wouldn't remove political concerns, for example. Nor
would it address Zone splits any better than the current approach does.
Although it might be worth adding abstract IDs to implement a larger
project, I'd like to see that larger project's outlines before opining.
> * An abstract region ID would naturally have no pre-1970 data, as it
> doesn't define data in a single city/location.
Sorry, I don't know what "naturally" refers to here. Aren't abstract IDs
orthogonal to eliminating pre-1970 data? After all, we could introduce
abstract IDs without eliminating pre-1970 data, and vice versa.
> timezone rules were entirely local in the US for about 20 years
Perhaps you are referring to 1946-1966? But US timezone rules were local
for considerably more than twenty years (1883-1917, 1920-1941, 1946-1966).
> 3) "An event will happen at this time in the future"
> If an end-user wants to store an event in the future, eg. a one hour
> meeting next month, the correct approach is to store the date, time
> and zone ID
That doesn't suffice, as it doesn't work if the Zone splits in the meantime.
> * In most parts of the world, this requires one ID per country
No, it requires far fewer Zones for this use case. I estimate that it
would require about 110 Zones, a bit fewer if we omit legacy Zones like
PST8PDT. That's far fewer than the 249 country codes in iso3166.tab.
(We'd need so few Zones because for this use case we could merge all
Zones agreeing in the future.)
> * One ID for each ISO country (as was the guideline in the past) is a
> reasonable minimum expectation of end users
I doubt that, given that we could get by with so few Zones for the given
> 4) "An event will happen at this time in the future relative to a
> shared/common definition"
> A TV show might be defined to air at 8pm Mountain Time in one months
> time. It will air at that time regardless of whether any of the states
> that are currently on Mountain Time change to Pacific Time.
I don't think we can realistically predict what will happen for future
events of this sort, which means this sort of thing should not be a
design constraint. tzdb needs flexibility, not a straightjacket, to deal
with unknown future events.
Suppose, for example, that in mid-2022 the US east coast switches from
-05 (-04 with DST) to -04 all year, something that's under serious
consideration. A TV show that was formerly planned for 2022-12-01 19:00
-05 will likely be rescheduled for 2022-12-01 19:00 -04, i.e., still 7pm
in New York, Philadelphia, Miami, etc. but with a different UTC. If such
a show had been scheduled with TZ='EST5EDT' then that TZ setting would
be wrong after the change; whereas if it had been scheduled with
TZ='America/New_York' it would be OK.
We can't predict how events like this will shake out. Nor should we be
compelled to add legacy-like Zones like "AEST-10AEDT" or
"<MSK+07>-10<MSK+07>" merely because of the existence of legacy zones
like "PST8PDT". Such complexity would be more trouble than it'd be
worth: there are good reasons we moved away from "PST8PDT" and the like.
> My understanding is that IDs in the `backward` file represent
> deprecated IDs that should not be used going forward.
My understanding has been that the names in 'backward' should be
supported indefinitely unless there is good reason to remove them. We
have on rare occasions removed 'backward' links (I recall
Canada/East-Saskatchewan; perhaps there were a few others) but I think
this was to fix bugs, not mere cleanups.
It sounds like we should document this issue better, if your
understanding is the reverse of mine.
> * It is hard at present to identify IDs that are deprecated because of
> proper aliasing, such as spelling changes, vs those where the ID is a
> real location but its TZDB status has been reduced.
Good point, and it'd be good to document somehow why Link entries exist.
Among other things, I suspect that there are more than just the two
reasons that you mention.
More information about the tz