<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
One thing to note is that there's some possibility that
distributions will be reluctant to deploy the (large) tzdata.zi file
<i>just</i> to have an official place where the version is deployed.
I would really like it if a separate <tt>version.zi</tt> file were
deployed alongside <tt>tzdata.zi</tt> that <i>just</i> contains
the version information.<br>
<br>
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:<br>
<br>
base_data_version: 2018c<br>
tzcode_version: 2018c<br>
<br>
Presumably a key for whether the files were generated from the <tt>rearguard</tt>
file would also be useful.<br>
<br>
<br>
<div class="moz-cite-prefix">On 07/23/2018 09:36 AM, Lester Caine
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:90fa7a4c-fef8-91a9-74a2-9dfe68a6370e@lsces.co.uk">OK I
am back in the office now with a decent email client ;)
<br>
<br>
On 20/07/18 00:40, Paul Eggert wrote:
<br>
<blockquote type="cite">Robert Elz wrote:
<br>
<blockquote type="cite">I have more than doubts, I am convinced
that the entire thing is
<br>
misguided, and that (with the one exception of curiosity
value,
<br>
the ability of an application to tell people which version
data it
<br>
is using) there is no good use of this data
<br>
</blockquote>
<br>
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.
<br>
</blockquote>
<br>
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.
<br>
<br>
<blockquote type="cite">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:
<br>
</blockquote>
<br>
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 ...
<br>
<br>
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.
<br>
<br>
</blockquote>
<br>
</body>
</html>