[tz] Getting current tzdb version in use

[Paul Ganssle]

One thing to note is that there's some possibility that distributions
will be reluctant to deploy the (large) tzdata.zi file /just/ to have an
official place where the version is deployed. I would really like it if
a separate version.zi file were deployed alongside tzdata.zi that /just/
contains the version information.

One option is to have the version.zi be a little richer than an empty
file with a version string, it could be a key-value store like:

base_data_version: 2018c
tzcode_version: 2018c

Presumably a key for whether the files were generated from the rearguard
file would also be useful.


On 07/23/2018 09:36 AM, Lester Caine wrote:
> 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.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20180723/c7cae21a/attachment.html>