[tz] TZDB use cases

Clive D.W. Feather clive at davros.org
Thu Oct 7 15:58:15 UTC 2021


Stephen Colebourne via tz said:
> > > 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.

How can you tell? If a business application is in use in a region that has
a split, I would expect it to affect the people in at least one half of the
split, if not both.

> The point above is documenting how things *are*. Business applications
> and calendaring systems really do store the local date/time and zone
> ID from TZDB for future events. This works precisely because there are
> enough IDs provided by TZDB to make this work.

Yes, and more. And it *does not* work if your data includes a zone that
gets split.

> If TZDB had only ever
> offered an ID for each abstract region, then *some other*
> system/project would have needed to be invented to define a set of IDs
> suitable for business applications.

No, it wouldn't. Assuming that we're sticking with post-1970 data, then a
business application would work just fine using "Europe/Berlin" for data
relating to Berlin, to Frankfurt, to Oslo, and to Stavanger.

> But TZDB doesn't just provide IDs for abstract regions, it has always
> provided more than that. 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.

Completely false. Please explain how the presence of the string
"Europe/Oslo", which is interchangable with the string "Europe/Berlin",
has made any difference.

> it is too late to get rid of IDs like Europe/Oslo and
> Atlantic/Reykjavik.

For backwards compatibility, yes, I agree and I think everyone else does.
But saying that "Europe/Berlin" and "Europe/Oslo" are equivalent works just
fine, just as saying that "Africa/Accra" and "Africa/Abidjan" are
equivalent does.

The business application only cares about the abstract regions, not the
specific strings. (In the guts, anyway; user interface is another
question.)

-- 
Clive D.W. Feather          | If you lie to the compiler,
Email: clive at davros.org     | it will get its revenge.
Web: http://www.davros.org  |   - Henry Spencer
Mobile: +44 7973 377646


More information about the tz mailing list