[tz] TZDB use cases

[Paul Eggert]

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.