On 28 August 2013 13:21, Marc Lehmann <schmorp@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@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@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@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@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@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