<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 30, 2013 at 3:29 AM, Stephen Colebourne <span dir="ltr"><<a href="mailto:scolebourne@joda.org" target="_blank">scolebourne@joda.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I oppose this direction for the tzdb on principle.<br>
<br>
TL;DR: The tzdb isn't broken. Don't fix it.<br>
<br>
In terms of the proposed patch, it is possible to use this structure,<br>
but requires extra work to do so. Parsing the new data will require<br>
changes to the 3 compilers I maintain. Gunther Vermeir has indicated<br>
that Oracle RDBS also has changes to make, which will be difficult to<br>
do. I suspect that there are others.<br>
<br>
Your patch generates the back-pre-1970 dynamically, rather than<br>
checking it in and releasing it in the distribution. That generation<br>
code is inaccessible to those who write compilers in other languages,<br>
thus the logic must be repeated. (The simplest solution is to process<br>
all links after all zones, and ignore links that have the same names<br>
as zones). The patch also requires changing the set of input files to<br>
be processed, adding attic.<br>
<br>
Beyond the immediate patch feedback, I just think this is entirely the<br>
wrong direction for the tzdb project.<br>
<br>
The key problems are (1) divergence in the meaning of an ID and (2)<br>
change for changes sake.<br>
<br>
The tzdb currently offers two basic sets of data - "right" (with<br>
leapsecs) and "normal". The number of people using "right" is very<br>
small, and the associated local time differences are also very small,<br>
so the "right" files can be mostly ignored. By contrast, this approach<br>
adds another set of data, one which feedback is demonstrating will be<br>
relatively widely used.<br>
<br>
As such, what this approach does is create a divergence in the meaning<br>
of a time-zone ID, of the kind that has not happened before. This is a<br>
big no-no to me. My experience with similar problems (divergence<br>
between the meaning of an ID between Joda-Time and the Java JDK)<br>
indicates that users find it confusing and consider it a bug. One ID<br>
should mean the same wherever it is used, from Unix to Java to PHP -<br>
that is the ubiquity aspect of the "Principles" email I sent out.<br>
<br>
For example, with this approach, the ID "America/Atikokan" will have<br>
two very different sets of time-zone history associated with it. A<br>
user looking at the zone on a Unix command line will see a different<br>
history to that viewed through Java (or PHP from the sounds of it).<br>
This difference is hugely negative for my users.<br>
<br>
The alternative approach, which I am arguing for, is to make no change<br>
at all. Simply leave the data as it was in the tzdb. The key principle<br>
is that once you have created an ID, you have a responsibility to<br>
maintain it in the long term, and that applies to all data, pre and<br>
post 1970. Whether the data is good, bad or indifferent is not<br>
important - backwards compatibility matters more. (Note that<br>
enhancements to history based on research continue to be fine).<br>
<br>
That is what I desribe as stability. I'm pretty sure its what lots of<br>
those who have joined in the thread in some small way expressing<br>
discomfort have been looking to achieve.<br>
<br>
Note: I don't object to the addition of filters in zic, but they<br>
should be switched off by default to avoid divergence of ID meaning as<br>
much as possible.<br>
<br>
<br>
To the extent I can, I'm trying to exercise a veto on this change and<br>
the entire set of recent amendments. I hope I've expressed why in<br>
clear enough terms. I also doubt that you have or will get consensus<br>
to push through such a change.<br>
<br>
I am sorry that you have made a rod for your own back here. Your<br>
attempt to reduce controversy has clearly failed IMO - your cure is<br>
worse than the disease:<br>
<a href="https://github.com/eggert/tz/commit/d3b025adb25554ee10b986850371e573df92733e" target="_blank">https://github.com/eggert/tz/commit/d3b025adb25554ee10b986850371e573df92733e</a><br>
<br>
I encourage others who simply want to see tzdb ID history preserved<br>
without change (and a focus placed back on current Government changes)<br>
to add a +1 to this email.<br></blockquote><div><br></div><div>+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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Stephen<br>
</font></span></blockquote></div><br>
</div></div>