On 3 September 2013 22:27, Russ Allbery <rra@stanford.edu> wrote:
Stephen Colebourne <scolebourne@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, https://github.com/eggert/tz/commits/master/backward 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. Stephen