[tz] Unacceptable recent changes [wasRe: [PATCH 2/4] Move obsolescent Americas entries to 'backward'.]

[Tim Parenti]

On 28 August 2013 13:21, Marc Lehmann <schmorp at schmorp.de> wrote:

> The interpretation I always gave this, and that was consistent with the
> "old style maintainance regime", is that pre-1970s data is not guaranteed
> to be correct, useful, or complete, but it is occasionally maintained at
> best effort base. This can be witnessed by the many pre-1970 changes to
> the data over the years.
>
> I think the part you quoted contradicts your recent actions - the fact
> that the data isn't provided everywhere implies that data is provided
> somewhere, and overall, this part of the Theory file gives no reason to
> actively remove pre-1970 data.
>
> The pre-1970 cut-off, IMHO, was always meant as the date from where the tz
> database really cares and really tries to get right, while earlier tz data
> might be completely wrong, and definitely much less certain.
>

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.

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.,
http://blog.jonudell.net/2009/10/23/a-literary-appreciation-of-the-olsonzoneinfotz-database/).
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.

On 28 August 2013 12:46, Paul Eggert <eggert at cs.ucla.edu> wrote:

> After all, the pre-1970 data
> for Atikokan was almost surely incorrect, and nobody cared
> about that either.
>

If, by "almost surely incorrect", you mean "as good as we or anyone has
really ever been able to compile".

On 28 August 2013 13:23, Paul Eggert <eggert at cs.ucla.edu> wrote:

> If we relaxed this rule, and allowed multiple regions
> even though their clocks agreed since 1970, that will
> be a recipe for more political disputes.
>

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.

On 28 August 2013 15:18, Paul Eggert <eggert at cs.ucla.edu> wrote:

> It is inconsistent to give the Navajo reservation its own zone
> while not extending the same privileges to the Hopi.  And a
> similar argument applies to the Osage, Yakama, Flathead,
> Wind River, and Rosebud reservations.
>

Actually, the America/Shiprock change is just about the only proposed
'backwards' change I support, for this very reason.

On 28 August 2013 13:49, Zefram <zefram at fysh.org> wrote:

> There should be some project that tackles pre-1970 timezones
> systematically.  My preference would be for the tz project itself to
> do this.
>

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.

On 28 August 2013 15:59, Alan Barrett <apb at cequrux.com> wrote:

> 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.


And this seems a very reasonable way to approach this.

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.

--
Tim Parenti
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20130828/93b72957/attachment.html>