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

On 8 August 2014 02:25, Alan Barrett <apb@cequrux.com> wrote:
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.

The stability-related complaints have been about cases where the "more correct than the old data" condition was not perceived to be satisfied.

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.

I, too, am gradually coming around to this stance, and for the same reasons.  Among the reasons I'm not yet fully on board:

On 5 August 2014 12:07, Paul Eggert <eggert@cs.ucla.edu> wrote:
Marc Lehmann wrote:
I haven't seen anybody argue the new data is better.

It appears you overlooked some arguments in that direction; see <http://mm.icann.org/pipermail/tz/2014-August/021283.html> for example.

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.

On 6 August 2014 14:32, Paul Eggert <eggert@cs.ucla.edu> wrote:
Lester Caine wrote:
If it is proven wrong because there is a
proven correct version then OK, but switching one unproven fact with
another ...

Those changes mostly remove dubious data, rather than replacing one dubious datum with another.

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:

On 6 August 2014 14:58, Lester Caine <lester@lsces.co.uk> wrote:
If the removing of dubious data results in the answers generated
changing then that is the stability that is objected to. These changes
resulting new output that is only changing because of two lots of
dubious states is the problem

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.

* * *

On 6 August 2014 14:32, Paul Eggert <eggert@cs.ucla.edu> wrote:
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.

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

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.

On 5 August 2014 11:40, Stephen Colebourne <scolebourne@joda.org> wrote:
Simply ploughing on with the changes, just in smaller batches, does
not actually make the objectors happy

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.

On 8 August 2014 05:07, John Hawkinson <jhawk@mit.edu> wrote:
Perhaps this work should continue in bite-size portions on a branch
until it is finally done, and only then should that branch be merged
to the trunk and released.

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.

--
Tim Parenti