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.