[tz] TZDB use cases
eggert at cs.ucla.edu
Mon Oct 4 07:29:18 UTC 2021
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
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
> 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
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.
More information about the tz