[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