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

[Zefram]

Stephen Colebourne wrote:
>Sorry to be unsubtle, but I think we're approaching vote of no
>confidence territory here.

I, for one, continue to have confidence in Paul Eggert's maintainership.
On zone.tab he's reached a good compromise, which reduced the
political pressure while avoiding throwing away the bulk of useful data.
On pre-1970 data, throwing away all pre-1970 distinctions obviously isn't
going to fly, and Eggert has already acknowledged this and is modifying
his approach.  He is responsive to the discussion on the list.

My opinion on pre-1970 data is that I'd rather not lose any of the data
the project has collected, but the stated scope of the tz project does
have effects that can't be ignored.  If you want proper handling of
pre-1970 timestamps then the tz database isn't sufficient: the zones
that it distinguishes pre-1970 are a matter of historical accident,
not any systematic treatment.  The zones whose conversion to links Paul
Eggert has proposed are indeed an anomaly.

There should be some project that tackles pre-1970 timezones
systematically.  My preference would be for the tz project itself to
do this.  It could be done gradually, by first permitting new zones
(for which there's decent data) to be added that differ from existing
ones only pre-1970, and eventually by progressively reducing that 1970
threshold to increase the project's formal scope.  This is essentially
the opposite of Paul Eggert's approach to resolving the anomaly.
Another sane option is to limit the official tz database to zones that
are distinct post-1970 and have a separate project develop a larger
database that takes the more inclusive approach.  Or a middle course is
to maintain both collections in the tz project with a two-tier structure,
the larger database being installed only where specifically requested.
The "attic" concept is a step in that direction.

Any proposal for a tz database of wider scope has to deal with the
technical effects of a larger collection of zones.  The compiled tzfiles
(and to a lesser extent the source files) don't share data representation
between zones, so twice as many zones means twice as much disk usage.
Selection of a timezone for present-day purposes is hampered by the
existence of multiple zones that don't differ recently enough to matter.
There are ways to fix these problems, of course, but they mean that
the database can't just be casually expanded.  Hence the sense of a
two-tier structure.

So, in summary: if you want proper handling of pre-1970 timezones then
you want something that the tz database doesn't supply.  We need some
other kind of effort to supply it.  And how that effort relates to the
present tz project, from among the sane options, isn't a matter for
no-confidence votes.

-zefram