[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é
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
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
More information about the tz