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

[enh]

On Fri, Aug 30, 2013 at 3:29 AM, Stephen Colebourne <scolebourne at joda.org>wrote:

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

+1 --- i think the arguments that apply to Joda-Time and the JDK apply
equally to Android's C library and Java libraries, both of which use this
data. it's hard to justify changing something unless it was demonstrably
wrong before and is demonstrably less wrong after.


>
> Stephen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20130830/1717a671/attachment-0001.html>