[tz] Getting current tzdb version in use

Robert Elz kre at munnari.OZ.AU
Thu Jul 19 21:34:56 UTC 2018


    Date:        Thu, 19 Jul 2018 07:51:28 -0700
    From:        Paul Eggert <eggert at cs.ucla.edu>
    Message-ID:  <b29fe5b7-1475-f583-dbaf-ca43782bebcf at cs.ucla.edu>

  | I have my doubts about the version info.

I have more than doubts, I am convinced that the entire thing is
misguided, and that (with the one exception of curiosity value,
the ability of an application to tell people which version data it
is using) there is no good use of  this data in the way it is being
mooted that should not be handled a different way, and that
anything using the tzdata version for this (like using the results of
that c++ interface that was mentioned) will cause more problems
than it can ever solve.

To consider the one example that was presented here in the past
dat or so - the long running airline application that wants to auto
update the tzdata files as needed.   That's a reasonable aim.

But putting version info in the data is neither needed, nor useful
for that.    The assumption is that the app can look and see if a
new version of the data has appeared, compare with the running
version, and update as needed.    Fine.   But to discover what the
new version is cannot be using version info in the data, as that
data does not exist yet, only the sources,   The app must be using
either the version info in the file names, or the version info in the
version file.    When it updates, it can store that "new" version
info anywhere convenient to it, which when the update is done,
will become the "version in use" that it can use when looking for
the next update to appear.

What's more, this is really all part of the packaging system (whether
that is something built into the application, or something separate)
and not part of the mainstream of the application.

Further, depending upon how it is done, putting version info into
the data files can be counterproductive, and result in lots of churn.
Eg: sometime (probably not too far away) we are going to get
2018f - in that the zone file for Fiji is going to be changed, and
anyone who updates to that version will get new data for Fiji,
But there is (unless I have forgotten some other pending change)
no need for any of the other zone files to alter, and a system might
very well detect that, and only update the zones that actually contain
different data, rather than all of them,   That results in a much more
stable system - but if those files contain version info, soon enough there
will be many different installed versions.   If the version info is to be
somewhere else, then the system might just as well install the
"version" file somewhere, and use that (assuming it can find a reliable
use for it).

Longer ago, perhaps the last time this issue came up, or perhaps
one of the tmes before that, there was some suggestion that software
could automatically update times to account for changes to the zone
data.   Even assuming this is rational (which I doubt) version info is
not needed (or useful) for that - what is wanted is the "old" data, and
the "new" data (whatever they call themselves) and the ability to
read both, and compare whatever it is needs comparing.   For this
nothing cares whether the old data is 2018d or 2015c when you're
updating to 2018e (nor that the new version is called that) - just
that "we used to get this conversion, we now get this other one,
which means we should ..."

As to the "assuming it s rational" - just go back to the airline example
again.   We know there is going to be a week when (in Fiji) the old
and new tzdata (2018e and 2018f) give different results.   But to
believe from that the flight times into or out of Suva need to simply
be adjusted by an hour would be lunacy.    For example, internal
flights (within Fiji) will almost certainly continue to operate at the
same local wallclock times, which will be an hour earlier (or later,
I forget what the change was) in UTC equivalent time for a week
than what they would have been.   On the other hand, international
flights get far more complex - they can't just be moved bty an hour, as
that would upset the scheduelling (including gate availability,
congestion for takeoff/landing ...) at the other end of the flight,
plus not arriving too lage for connecting flights (on other airlines
which do not fly to Fiji and have no reason to alter anything), and
to deal with airport curfews, etc.    It all gets horribly complex, and
can't be handled trivially.

Of course, the Fiji case is not all that hard, as the new schedule
already exists, the only question is which day the switch is made
from old to new ... well, almost, there's still a lot of coordination
involved, when the "new" means changes that affect operations
at other places, and so everything needs to be coordinated.

For most other applications, if the correct data is stored,  nothing
will care if the offsets change (not that nothing will be affected,
just that it will all take care of itself) - things only go wrong when
apps attempt to short-cut handing of time data, rather than doing
it properly.

Forget this. - leave version info alone, we have quite enough of it
already, and do not need more, and certainly do not need a method
for any random application that happens to call localtime() to find
out which tzdata version was used.

kre



More information about the tz mailing list