<div dir="ltr"><div class="gmail_extra"></div><div class="gmail_extra">I'm going to attempt to synthesize a lot of the recent discussion with respect to where I stand, as well as one way we could proceed...<br></div><div class="gmail_extra">
<br><div class="gmail_quote">On 8 August 2014 02:25, Alan Barrett <span dir="ltr"><<a href="mailto:apb@cequrux.com" target="_blank">apb@cequrux.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div id=":4gd" class="" style="overflow:hidden">Yes,
valuing correctness over stability is good, even when the new data is
not 100% correct, provided it is more correct than the old data.<br>
<br>
The stability-related complaints have been about cases where the "more
correct than the old data" condition was not perceived to be satisfied.<br>
<br>
I am gradually coming round to the opinion that the new data is probably
more correct than the old data, but that is not clear to all observers.</div></blockquote></div><br></div><div class="gmail_extra">I, too, am gradually coming around to this stance, and for the same reasons. Among the reasons I'm not yet fully on board:<br>
</div><div class="gmail_extra"><div class="gmail_extra"><br><div class="gmail_quote">On 5 August 2014 12:07, Paul Eggert <span dir="ltr"><<a href="mailto:eggert@cs.ucla.edu" target="_blank">eggert@cs.ucla.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Marc Lehmann wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I haven't seen anybody argue the new data is better.<br>
</blockquote>
<br></div>
It appears you overlooked some arguments in that direction; see <<a href="http://mm.icann.org/pipermail/tz/2014-August/021283.html" target="_blank">http://mm.icann.org/pipermail/tz/2014-August/021283.html</a>> for example.</blockquote>
</div><br></div>This
post only addresses the changes to a few of the zones. If you assert that the rest of the changes are
also better for similar reasons, that's one thing, but to date, I don't think this has been done. Depending on the nature of the assertion(s), they may or may not require fuller documentation to become convincing.<br>
<br><div class="gmail_quote">On 6 August 2014 14:32, Paul Eggert <span dir="ltr"><<a href="mailto:eggert@cs.ucla.edu" target="_blank">eggert@cs.ucla.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>Lester Caine wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If it is proven wrong because there is a<br>
proven correct version then OK, but switching one unproven fact with<br>
another ...<br>
</blockquote>
<br></div>
Those changes mostly remove dubious data, rather than replacing one dubious datum with another.</blockquote></div><br>I
believe the relevant point made by objectors here is that, by doing anything other than deleting the identifiers altogether, there is no such thing as "removing" data from an
end user's perspective, again, because the format minimally requires that something be there. Date and time tools using tz will still output
a wall clock time for a given tz identifier and historic UNIX
timestamp, and the new assertions in this space are the ones which (in
many cases) have no more proven merit than the old versions. I believe
this distinction of the actual Zone line data (and zic'd binaries) we
input from the end user "data" (and wall clock times) that tools output
is an important one to make here, as it lies at the heart of much
objection to these changes:<br><br>On 6 August 2014 14:58, Lester Caine <span dir="ltr"><<a href="mailto:lester@lsces.co.uk" target="_blank">lester@lsces.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="overflow:hidden">If the removing of dubious data results in the answers generated<br>
changing then that is the stability that is objected to. These changes<br>
resulting new output that is only changing because of two lots of<br>
dubious states is the problem</div></blockquote><br>
<div class="gmail_extra">As for the scope of the disruption caused by
these changes, in general, I find it difficult to buy either argument
that the supposed disruption is (a) so large as to prohibit the change,
or (b) so small as to override all other concerns. Due to the age of the timestamps affected, I'm more inclined to lean toward the "small" side of this debate, but due to my cautious nature I'm also inclined to overestimate the impacts by an order-of-magnitude or two. Further, just because no one has complained to us does not mean issues don't exist, or have even been discovered by users. In the end, I think reality is somewhere in the middle, and that these are weak arguments on both sides.<br>
</div><div class="gmail_extra"><br>* * *<br><br><div class="gmail_quote">On 6 August 2014 14:32, Paul Eggert <span dir="ltr"><<a href="mailto:eggert@cs.ucla.edu" target="_blank">eggert@cs.ucla.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In
the long run it'd be better to remove dubious data, or at least move it
to a "dubious" area optionally available to users who prefer it; but
one step at a time.</blockquote>
</div><br></div><div class="gmail_extra">I think this is the direction
we should move toward at this juncture. Perhaps frustratingly, the first task
would be to restore the zone data (and associated commentary) removed in 2013e and 2014f to
this new area. (I would have suggested "attic" for this file, but "dubious" is more straightforward and also avoids another file starting with "a").<br>
<br></div><div class="gmail_extra">From a build procedure standpoint,
and to avoid disrupting the main database, I think the simplest approach
would be to add a Makefile target which compiles the standard
files as usual, then compiles the dubious data with a separate call to
zic. If I am not mistaken, this would simply overwrite the binaries created from links in the standard files with binaries representing the more suspect data. It's a bit of unnecessary work for the compiler, yes, but this would simply factor into an administrator's decision whether to include this data.<br>
<br>On 5 August 2014 11:40, Stephen Colebourne <span dir="ltr"><<a href="mailto:scolebourne@joda.org" target="_blank">scolebourne@joda.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div id=":4fg" class="" style="overflow:hidden">Simply ploughing on with the changes, just in smaller batches, does<br>
not actually make the objectors happy</div></blockquote>
<br></div><div class="gmail_extra">In terms of maintenance procedure, I think we need to be just as cautious to observe due diligence as when we add new data. This takes on a different tone when relegating dubious data, but should still be of importance to the project.<br>
<br></div><div class="gmail_quote">On 8 August 2014 05:07, John Hawkinson <span dir="ltr"><<a href="mailto:jhawk@mit.edu" target="_blank">jhawk@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div id=":4s1" class="" style="overflow:hidden">Perhaps this work should continue in bite-size portions on a branch<br>
until it is finally done, and only then should that branch be merged<br>
to the trunk and released.</div></blockquote></div><br></div><div class="gmail_extra">And I think that, once the new file and build procedure are in place, this is one reasonable way (among many) to move forward with this plan.<br>
</div><div class="gmail_extra"><br clear="all"><div>--<br>Tim Parenti<br></div>
</div></div>