On 10/2/21 3:02 PM, Stephen Colebourne via tz wrote:
An abstract region represents a part of the Earth that has had the same clock rules since 1970. At some point prior to 1970 different locations within the abstract region had different clock rules, even if that was just LMT.
Thanks, I understand that notion better now.
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.
Of course that is true. But this hasn't been a problem in practice for business applications AFAICT.
If we could ignore problems as significant as Zone splits, we would have a lot of leeway. As you suggested earlier, we could even discard all pre-1970 data, as that would be less of a practical problem than Zone splits are. However, I doubt whether Zone splits are that easy to ignore. Granted, Zone splits don't happen every day - I think the most recent one was in 2018 when Asia/Qyzylorda hived off Asia/Qostanay. However, I expect that the roughly 800,000 people in the newly-created Zone had generated a fair number of affected timestamps in their business planning and scheduling.
by providing separate IDs like Europe/Oslo and Atlantic/Reykjavik for many years, TZDB has provided the basic tools necessary for business applications to function in the way described above.
Sure, and those IDs are still there and still supported. I think we agree that IDs like Europe/Oslo should continue to exit.
IMO, it is important to ensure that IDs exist for such shared zones. But luckily enough we already have "US/Mountain" and "CET", so the ID part is already sorted (in the US and EU).
Unfortunately even that is not sorted. There's a good chance that neither "US/Mountain" nor "CET" will work the way users might expect, if the US and Europe change time zone rules in ways that are seriously being discussed by political leaders. For example, suppose a few US/Mountain locations (just Idaho, say) decide to continue with current US/Mountain rules while most US/Mountain locations switch to CST (something that tzdb currently has no Zone for). In that case, if we had only Zones like "US/Mountain" we'd be asking most users to change their TZ settings, which'd be worse than the current system where "America/Denver" should continue to work for most users. Originally, tzdb started out with zones like "US/Mountain" and "CET". However, when I added data for the rest of the world, I discovered that the old approach didn't generalize well to places less centralized than US and the EU. It was stretching to even apply that old scheme to Australia, where different states in the same time zone sometimes (but not always) use different DST rules. I didn't offhand see how to apply the old approach to Russia (which uses a different system mostly unknown in the West, and which was chaotic in the 1990s), much less Africa, the Pacific, etc. I'm not saying it couldn't have been done (at least in theory) given enough time and research into all the legal definitions of time, but the time wasn't available and the research has never been done.
While I can understand the conceptual desire to have TZDB only provide abstract regions, it seems completely impractical to do so at this point
I agree, as mentioned above. For compatibility reasons we should provide names like Europe/Oslo into the indefinite future. If this isn't already clear in the guidelines it'd be good to make it clear.