[tz] [PATCH] New file 'pre1970' for zones that differ only in pre-1970 time stamps.

[Stephen Colebourne]

I oppose this direction for the tzdb on principle.

TL;DR: The tzdb isn't broken. Don't fix it.

In terms of the proposed patch, it is possible to use this structure,
but requires extra work to do so. Parsing the new data will require
changes to the 3 compilers I maintain. Gunther Vermeir has indicated
that Oracle RDBS also has changes to make, which will be difficult to
do. I suspect that there are others.

Your patch generates the back-pre-1970 dynamically, rather than
checking it in and releasing it in the distribution. That generation
code is inaccessible to those who write compilers in other languages,
thus the logic must be repeated. (The simplest solution is to process
all links after all zones, and ignore links that have the same names
as zones). The patch also requires changing the set of input files to
be processed, adding attic.

Beyond the immediate patch feedback, I just think this is entirely the
wrong direction for the tzdb project.

The key problems are (1) divergence in the meaning of an ID and (2)
change for changes sake.

The tzdb currently offers two basic sets of data - "right" (with
leapsecs) and "normal". The number of people using "right" is very
small, and the associated local time differences are also very small,
so the "right" files can be mostly ignored. By contrast, this approach
adds another set of data, one which feedback is demonstrating will be
relatively widely used.

As such, what this approach does is create a divergence in the meaning
of a time-zone ID, of the kind that has not happened before. This is a
big no-no to me. My experience with similar problems (divergence
between the meaning of an ID between Joda-Time and the Java JDK)
indicates that users find it confusing and consider it a bug. One ID
should mean the same wherever it is used, from Unix to Java to PHP -
that is the ubiquity aspect of the "Principles" email I sent out.

For example, with this approach, the ID "America/Atikokan" will have
two very different sets of time-zone history associated with it. A
user looking at the zone on a Unix command line will see a different
history to that viewed through Java (or PHP from the sounds of it).
This difference is hugely negative for my users.

The alternative approach, which I am arguing for, is to make no change
at all. Simply leave the data as it was in the tzdb. The key principle
is that once you have created an ID, you have a responsibility to
maintain it in the long term, and that applies to all data, pre and
post 1970. Whether the data is good, bad or indifferent is not
important - backwards compatibility matters more. (Note that
enhancements to history based on research continue to be fine).

That is what I desribe as stability. I'm pretty sure its what lots of
those who have joined in the thread in some small way expressing
discomfort have been looking to achieve.

Note: I don't object to the addition of filters in zic, but they
should be switched off by default to avoid divergence of ID meaning as
much as possible.


To the extent I can, I'm trying to exercise a veto on this change and
the entire set of recent amendments. I hope I've expressed why in
clear enough terms. I also doubt that you have or will get consensus
to push through such a change.

I am sorry that you have made a rod for your own back here. Your
attempt to reduce controversy has clearly failed IMO - your cure is
worse than the disease:
https://github.com/eggert/tz/commit/d3b025adb25554ee10b986850371e573df92733e

I encourage others who simply want to see tzdb ID history preserved
without change (and a focus placed back on current Government changes)
to add a +1 to this email.

Stephen