[tz] Getting current tzdb version in use
Lester Caine
lester at lsces.co.uk
Mon Jul 23 13:36:11 UTC 2018
OK I am back in the office now with a decent email client ;)
On 20/07/18 00:40, Paul Eggert wrote:
> Robert Elz wrote:
>> 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
>
> Yes, that's the only good use I can think of as well. That is, the
> version string is more for diagnosing obsolete or misconfigured systems
> than for use in ordinary computation. That being said, configuration is
> of growing importance in software engineering, and I hope that the
> version comment in tzdata.zi is enough to satisfy needs in this area.
The simple question that the provision of a version number allows one to
answer is "what version of tz data was used to create the material being
published". Since we can't rely on just which version a client machine
IS using, there has to be some way to identify just what WAS used, even
if that requires the site ALSO providing it's own copy of the tz rules
used! Calendars for international meetings are produced perhaps two or
three years in advance, so it is quite possible that in the intervening
time some element of normalised data will change, and at the very least
the organisers need to be aware of the problems created. THEY at least
need to be able to 'un-normalise' using the original rules and then
establish where cross timezone events have now been 'broken'. Assuming
the diary will still work with the data the OS is providing simply does
not work.
> With TZDIST the version info is best done via ETags, and this should
> work with TZif files so that clients can easily see whether they're
> up-to-date and get a new version if not. See Internet RFC 7808 section
> 4.1.4 along with:
ETags ONLY work for the person who originally normalised the data! Other
users need to know what version of tz data to ask for to go with the
diary they are reading and that may not be the 'current' tz data so if
tzdist is to be of any use, it needs to provide the requested rule set.
Something that ETags does nothing to support. In practice the publisher
of the data may not even be using TZ at all, so in addition to the
version, the creator of the diary would probably have to publish the the
source of the tzdist feed they are using ...
Note ... none of the above even touches on pre-1970 variations in the
raw data, but fixing the problem for current data will allow that data
to be viewed in 30 or 50 years time without having to worry about
changes in the meantime.
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
More information about the tz
mailing list