[tz] Inappropriate project direction

[Paul Eggert]

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 
be never-ending.

> 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 
prescribe it.

> - 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 
this area.

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.