<div dir="ltr"><div class="gmail_extra"><div class="gmail_extra"><div class="gmail_quote">On 28 August 2013 13:21, Marc Lehmann <span dir="ltr"><<a href="mailto:schmorp@schmorp.de" target="_blank">schmorp@schmorp.de</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">The interpretation I always gave this, and that was consistent with the<br>
"old style maintainance regime", is that pre-1970s data is not guaranteed<br>
to be correct, useful, or complete, but it is occasionally maintained at<br>
best effort base. This can be witnessed by the many pre-1970 changes to<br>
the data over the years.<br>
<br>
I think the part you quoted contradicts your recent actions - the fact<br>
that the data isn't provided everywhere implies that data is provided<br>
somewhere, and overall, this part of the Theory file gives no reason to<br>
actively remove pre-1970 data.<br>
<br>
The pre-1970 cut-off, IMHO, was always meant as the date from where the tz<br>
database really cares and really tries to get right, while earlier tz data<br>
might be completely wrong, and definitely much less certain.</div></blockquote></div><br></div><div class="gmail_extra">I
never thought the scope of the tz project to have been exclusionary,
e.g., "pre-1970 is NOT in scope", but rather inclusionary, e.g.,
"post-1970 is IN scope". I never got the sense previously that pre-1970
data was an ending point for things to throw away; just that it was a
practical starting point for things TO include. I think the reasons
behind this were fairly well-established.<br><br>It has been my understanding that the tz project has evolved into just
as much a historical document as a systems project; and it is highly
regarded by many for this purpose as well as its original intent (see,
e.g.,
<a href="http://blog.jonudell.net/2009/10/23/a-literary-appreciation-of-the-olsonzoneinfotz-database/" target="_blank">http://blog.jonudell.net/2009/10/23/a-literary-appreciation-of-the-olsonzoneinfotz-database/</a>).
In observing list discussion prior to this point, the consensus Rule #0
has always seemed to be stability over everything. Even when this project has
occasionally strayed outside the scope of Theory, we have VERY strongly
avoided changing ANY data unless it's demonstrably wrong. Many of the
currently proposed changes represent a major shift in that philosophy, I
think for misguided reasons.<br><br><div class="gmail_quote">On 28 August 2013 12:46, 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 style="overflow:hidden">After all, the pre-1970 data<br>
for Atikokan was almost surely incorrect, and nobody cared<br>
about that either.</div></blockquote></div><br></div>If, by "almost surely incorrect", you mean "as good as we or anyone has really ever been able to compile".<br><br><div class="gmail_quote">On 28 August 2013 13:23, 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 style="overflow:hidden">If we relaxed this rule, and allowed multiple regions<br>
even though their clocks agreed since 1970, that will<br>
be a recipe for more political disputes.</div></blockquote></div><br></div><div class="gmail_extra">The
problem here is that that rule was already relaxed long ago, presumably
with some reason behind it (even if flawed). Removing this data may
solve one problem (although I'd argue it doesn't), but it certainly
causes more.<br>
<br><div class="gmail_extra"><div class="gmail_quote">On 28 August 2013 15:18, 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 style="overflow:hidden">It
is inconsistent to give the Navajo reservation its own zone<br>
while not extending the same privileges to the Hopi. And a<br>
similar argument applies to the Osage, Yakama, Flathead,<br>
Wind River, and Rosebud reservations.</div></blockquote></div><br></div>Actually, the America/Shiprock change is just about the only proposed 'backwards' change I support, for this very reason.<br>
<br><div class="gmail_extra"><div class="gmail_quote">On 28 August 2013 13:49, Zefram <span dir="ltr"><<a href="mailto:zefram@fysh.org" target="_blank">zefram@fysh.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 style="overflow:hidden">There should be some project that tackles pre-1970 timezones<br>
systematically. My preference would be for the tz project itself to<br>
do this.</div></blockquote></div><br></div><div class="gmail_extra">This
is my preference as well, and we are most equipped to handle it, since
this is by far one of the most established projects in this space.<br></div><br><div class="gmail_extra"><div class="gmail_quote">On 28 August 2013 15:59, 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">Increasing
the quality of pre-1970 data may require creating new zones, and I
think it would be fine if such new zones were handled in a way that
allows distributors to choose whether or not to include them. For
example, there could be different versions of zone.tab that do or do not
include cities that differ only in pre-1970 timestamps, and there could
be Makefile options to control whether or not such additional zones are
installed.</blockquote></div><br></div>And this seems a very reasonable way to approach this.<br><br></div><div class="gmail_extra">I,
for one, am not currently in the "no confidence" camp, as Paul has been responsive and engaged with these concerns; however, these proposed
changes to the data do have me very concerned about the future direction
of this project. I hope that they are summarily reversed.<br></div><div class="gmail_extra"><br clear="all"><div>--<br>Tim Parenti<br></div>
</div></div>