<div>THIRD TRY ON THIS BLOODY PHONE!<br/>
If the data being used has been normalized using pre-<a href="tel:1970">1970</a> information but the tz service has omitted it then how do you identify the problem. More important how do you provide the correct data? And that is before adding the version of tz data used to do the normalization. The version number is essential data even for current normalized data, backzone just adds to the problem of establishing which data was used. See discussion on tzdist for more detail on managing current timetables which may have changes while one is in flight mode .... and when syncing again differences are flagged via version change.<br/>
<br/>
<font color="#888888"><font color="#888888">Sent from my android device so quoting is crap ... need to kill these painful email clients!</font></font><br/><br/>-----Original Message-----<br/>From: Paul Ganssle <paul@ganssle.io><br/>To: lester@lsces.co.uk<br/>Cc: "tz@iana.org List" <tz@iana.org>, Bradley White <bww@acm.org><br/>Sent: Wed, 28 Oct 2015 4:38<br/>Subject: Re: [tz] Version in zoneinfo files?<br/><br/></div><p dir="ltr">I'm not sure I understand why backzone data needs to be part of the version tag. Isn't it sufficient to know the release version of the tzdata (as these are archived and available)?</p>
<div class="gmail_quote">On Oct 27, 2015 11:34 PM, <<a href="mailto:lester@lsces.co.uk">lester@lsces.co.uk</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>The major problem all the time is identifying just what rules were applied when processing historic data, which may actually only be a current meeting diary. One can not assume that the current rule set actually correctly translates the current data if one set predates a later change. But my own data goes back to a time when the rules were more suspect, and reprocessing that data can result in confusion. We need to be able to assess if changes do affect either current or historic data and without a clean version number that is not posible. Removing backzone data also screws up historic data even only back to thd second world war, so that needs to be part of any versioning tag.<br>
<br>
<font color="#888888"><font color="#888888">Sent from my android device so quoting is crap ... need to kill these painful email clients!</font></font><br><br>-----Original Message-----<br>From: Bradley White <<a href="mailto:bww@acm.org" target="_blank">bww@acm.org</a>><br>To: "<a href="mailto:tz@iana.org" target="_blank">tz@iana.org</a> mailing list" <<a href="mailto:tz@iana.org" target="_blank">tz@iana.org</a>><br>Sent: Mon, 26 Oct 2015 22:50<br>Subject: Re: [tz] Version in zoneinfo files?<br><br></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Oct 25, 2015 at 2:30 PM, Guy Harris <span dir="ltr"><<a href="mailto:guy@alum.mit.edu" target="_blank">guy@alum.mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Is this just something to let people know whether they have an up-to-date version of the tzdb files or not?<br></blockquote><div><br></div><div>Yes, although I think of it simply as let people know what version of a tzdb file they have. (Whether that is the latest version is a separate question.)</div><div><br></div><div>I would even propose an additional self-identification step: include the zone name in tzdb file. Then you could tell, for example, where /etc/localtime came from.</div></div></div></div>
</blockquote></div>