[tz] Inappropriate project direction
eggert at cs.ucla.edu
Fri Feb 9 22:36:26 UTC 2018
On 02/06/2018 08:13 AM, Stephen Colebourne wrote:
> 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
Those LMT values were not significant and their loss was no real loss.
The only significant effect that I recall was on test suites, and test
suites should not be forcing tzdb to continue to promote invented data.
> - downstream consumers had to change logic wrt the meaning of backzone
Downstream consumers don't have worry about backzone. Mostly, they
should just not use backzone, as it is outside the scope of tzdb proper
and contains data that is not installed by default.
> - it was culturally insensitive to not provide a primary Zone entry
> for some countries
tzdb focuses on timekeeping practices. We should spend as few of our
limited resources as possible to worry about political or cultural
sensitivities that have nothing to do with timekeeping proper. Although
we cannot exclude politics entirely, we should strive to not complicate
the database merely to make political partisans happy, a task that would
> 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
The few invented abbreviations that became common parlance were kept.
The remaining abbreviations lacked sufficient practical justification
for a database where the goal is to describe timekeeping practice, not
> - downstream consumers had to change logic to handle numeric-style identifiers
Applications like OpenJDK+CLDR that want abbreviations and full names
for every time zone needed to maintain their own databases of inventions
anyway. For tzdb-style abbreviations, numeric identifiers are more
accurate and less error-prone than invented ones, and have been part of
the POSIX standard since 2001.
> The main archive format was changed from the well-known and widely
> supported gz to the niche lz format.
This has not affected downstream consumers, which can continue to use
gzip format as before. Support for lzip is easily and freely available
on modern platforms, including MS-Windows. Microsoft itself didn't
support gzip back in the day, but that didn't mean we shouldn't have
used gzip back then.
> 4) Negative SAVE values ...
> - downstream consumers broke
The main downstream consumer that broke was OpenJDK+CLDR. The problem
was soon rectified, and because OpenJDK+CLDR is an important enough
consumer we now have a way in the development version to generate a form
of the tzdata source that does not use negative DST offsets. That being
said, the OpenJDK+CLDR model is incorrect for Irish timekeeping and it
really should get fixed at some point. Fractional seconds are a similar
sort of thing, though here CLDR has made it clear that they don't care
about timestamps before 1990, so this issue should not affect CLDR
(unless North Korea starts using a fractional-second UTC offset :-) and
only a trivial change to OpenJDK should be needed.
> Not one of these changes has added value to the project.
Even if there was no value to you, there is some value to record civil
timekeeping more accurately. Different consumers have different needs in
More importantly, there needs to be a better way for tzdb+OpenJDK+CLDR
to accommodate future changes, as there inevitably will be. Of course we
should not change things just for the purpose of changing. Conversely,
it would not be healthy to have a software system that can never be
changed and can never be improved. We should have a reasonable upgrade
strategy, as changes will be inevitable.
More information about the tz