[tz] TZDB use cases

[Paul Eggert]

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 
use case.


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