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.