[tz] Inappropriate project direction

Paul G paul at ganssle.io
Tue Feb 6 16:32:16 UTC 2018

You seem to think stability is the only thing that matters, but it is clearly a balancing act between accuracy and stability.

There have been repeated efforts to work out some compatibility mechanism for software broken by these "changes" (some are not really changes at all just incorrect assumptions made that happened not to have been violated before), and your response has been to just demand (none too kindly, for that matter) that zero changes ever happen in the future and no upgrade mechanism be provided.

If you need an unchanging version is this frozen in time and *cannot* use the compatibility versions for whatever reason, I suggest that you maintain a fork of the project. It wouldn't be amazingly difficult, you just would need to maintain a "downgrade" script and you'd still be able to take advantage of all the hard work of the volunteers maintaining this project without any of the pesky changes to improve the accuracy of the data.

On February 6, 2018 4:13:51 PM UTC, Stephen Colebourne <scolebourne at joda.org> wrote:
>In the last few years, the following changes have been made to the
>tzdb project. Each of these
>- added no value
>- had a cost that far exceeded the benefits
>- should not have happened
>1) Removal of Zone definitions from many countries.
>While the Zone definitions may have been the same across different
>countries, it was never appropriate to merge the time-zones of
>multiple different countries (backzone being the result).
>- the change caused LMT values to be lost
>- downstream consumers had to change logic wrt the meaning of backzone
>- it was culturally insensitive to not provide a primary Zone entry
>for some countries
>2) Removal of textual short zone names.
>While these names may well have been invented in some cases, the had
>often become de facto standards
>- end-users complained about the loss of textual names
>- downstream consumers had to change logic to handle numeric-style
>3) Move to a niche archive format
>The main archive format was changed from the well-known and widely
>supported gz to the niche lz format. There was and is no justification
>for using a niche format on a project as important as this one.
>- downstream consumers need to find and use the niche format
>- Windows does not have proper support for the niche format
>4) Negative SAVE values
>Despite being a known fact in tzdb since 2005, and despite being
>warned not to in advance, a decision to re-interpret the meaning of
>Ireland DST was pushed through.
>- downstream consumers broke
>- the interaction with CLDR is incompatible with negative DST
>- the change has no impact on actual times
>- even if someone thought it was broken, there are no benefits to
>making the change
>5) Fractional seconds
>A desire to fix subsecond data from over 50 years ago.
>- downstream consumers will break
>- the number of people who care is vanishingly small
>Were recent discussions a one-off, I might be prepared to let things
>lie, but as can be seen, there is a pattern here. Not one of these
>changes has added value to the project. Not one of them has been
>necessary to the primary mission of recording what governments are
>doing to their clocks now, nor even in the last 40 years. Worse, the
>majority are driven by a notion that getting the data "pure" trumps
>all problems reported by downstream consumers.
>It is long past time to accept that tzdb needs to focus on the primary
>mission - recording current government changes in a stable, backwards
>compatible manner.
>Tinkering needs to stop.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20180206/91716416/attachment.html>

More information about the tz mailing list