[tz] [PATCH 2/3] Replace some zones with links when that doesn't lose non-LMT info.

Stephen Colebourne scolebourne at joda.org
Wed Sep 4 09:32:11 UTC 2013

On 3 September 2013 22:27, Russ Allbery <rra at stanford.edu> wrote:
> Stephen Colebourne <scolebourne at joda.org> writes:
>> If you had made no changes since May, apart from to the C code and to
>> current local time, then I, and many others, would be entirely happy.
> I've been sitting on this comment for quite some time, but, seriously,
> haven't you noticed that it's trivial for you or anyone else to produce a
> tz distribution that satisfies these requirements?  If that's what you
> want, well, you have all of the tools required to do this right now, and
> could have been doing this since May with far less investment of effort
> than you're currently putting into long messages to this mailing list.
> I guess I don't understand why you seem so deeply invested in convincing
> Paul that you're right and he's wrong when it's fairly trivially possible
> for you to generate exactly the data that you want according to the
> criteria that you want followed without insisting that other people do the
> work for you.
> If you want to freeze all historical data in stone at the state they were
> in as of May of this year and only adopt forward-looking changes, then by
> all means do so!  Set up a web site, set up a Git repository, cherry-pick
> the changes you want, and enjoy the perfect control you then have over
> your data source.
> I have been following this mailing list for many, many years, and when I
> first started following it I read all messages to this list going back to
> the foundation of the list.  With that information in mind, I'm quite
> comfortable in saying that the maintenance policy that you're asking for
> is not the maintenance policy that ado used, and is not the maintenance
> policy that has ever been used for this project.  I don't understand why
> you're so insistent on pushing a different maintenance policy on the
> project against multiple objections instead of just filtering the project
> changes down to the ones you approve of and publishing your own work.

There are a number of points here.

Firstly, creating a fork of the data is entirely unsatisfactory.
Alongside stability, I have indicated that ubiquity is a key value of
the data. The same data is used everywhere from Unix to Java to mobile
phones. Creating a fork greatly devalues the data (the value of the
two parts is less than the value of the whole). In addition, the tzdb
charter requires changes to have consensus, so I have every right to
complain here.

Secondly, I'm not speaking on behalf of myself, but on behalf of Java
development generally. I'd also suggest that I'm expressing the
opinions of enterprise software development more generally (see the
comments to the list from Bloomberg and Oracle RDMS).

Thirdly, I note that the leading supporters of Paul's approach are
from an academic background (Paul, Guy, yourself). With respect, I
wonder if that academic background insulates from the needs of
enterprise software, primarily stability.

Fourthly, it seems to me that the recent batch of changes are far in
excess of what has happened over previous years. For example,
shows that the backward file was modified a number of times in the
past few years, but almost always for changes to the spelling or
naming of zone IDs (something which I've not opposed, even though I
know CLDR finds that problematic).

Finally, I'm NOT asking for all historical data to be frozen. I'm
asking for no historical data to be changed UNLESS the replacement is
a clear enhancement. This is a common sense and perfectly reasonable
request of the database. Its also how all well-resected APIs and data
sets (like CLDR) operate. Such an approach does explicitly rule out
zone ID merging that loses the start date of offsets or abbreviations,
even if those are guesswork/invented (because the replacement is not
an enhancement, its worse).

To be clear, I hate the fact that I'm having to write these emails. I
think this list should be incredibly quiet, only receiving an email
when a current time changes, or when someone does some historical
research into a zone. Its not my fault that the database maintainer is
insisting on making uneccessary and negative changes, and then refuses
to revert them when the lack of consensus is clear.

In summary, given the importance of the data set, and how it is
currently being abused, I have no choice but to pusue my objections.


More information about the tz mailing list