[tz] TZDB use cases

Michael H Deckers michael.h.deckers at googlemail.com
Sun Oct 3 20:58:18 UTC 2021


    On 2021-10-03 09:47, Stephen Colebourne via tz wrote:

> Instead, most
> business applications simply use "Europe/Oslo" to represent the
> concept. Effectively, this outsources both the ID and the upkeep of
> the mapping to tzdb.



     Thanks for the clear presentation of the issues for
     persistent data storage!

     From the viewpoint of SQL database system providers, one cannot
     "merge" Europe/Oslo with Europe/Berlin because tzdb does not
     (and can not) guarantee that they remain the equal in the
     future. Not even Africa/Asmera can be equated with Africa/Asmara
     when tzdb does not guarantee that Africa/Asmera will always
     remain to be linked to Africa/Asmara in the future as long as
     it exists. In fact, among the timezone names that were merged
     since 2013, two have been "unmerged" in the meantime (São_Tomé
     and Juba).

     Database systems are used to store consistent sets af data
     over decennials; hence they can only exploit invariants of
     tzdb that are guaranteed to hold across many releases. The
     local time scale offsets are modeled in SQL as "nondeterministic"
     data; these are expected to vary over time and cannot be used
     in constraints and thus cannot affect data consistency.

     Most of the guarantees made by tzdb seem to be subject to
     change in the next release, not just the "merges". For instance,
     the dst bit used to indicate "summer time" for about 20 years,
     but since 2018a, the dst bit could also indicate winter time
     (and it is *hard* to check when it indicates which). If a
     database system relied on the earlier definition, they had
     a serious problem convincing Irish users that "summer time"
     is used in winter.

     So it appears that the tzdb data description does not make any
     long time guarantees except for standardized names for locations,
     and one or two local time scales for each location. (And that
     certainly is a praiseworthy feat and deserves our utmost
     respect!) The second local time scale (the one in /backzone),
     if any, is probably the better guess of the local time scale at
     the location indicated by its name, but that is not guaranteed
     either. Actually, it is not even true that the two time scales
     always agree after 1970, although most people seem to believe
     otherwise.

     So I think that database system providers can exploit tzdb only
     by using (practically all) the tzdb timezone names, without
     any "merging", and selecting for each of them one of the two
     local time scale definitions, as they see fit. In my opinion,
     this "cherry picking" is necessary and becomes more difficult
     when more time scale definitions are moved to backzone, and
     unnecessarily so.

     Michael Deckers.



More information about the tz mailing list