[tz] Inappropriate project direction

Mark Davis ☕️ mark at macchiato.com
Sun Feb 11 06:18:24 UTC 2018


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

I still fail to see why you think this is the case. With the current TZDB,
in CLDR and clients that use it, for English:

   - the time in July in Ireland is called "Irish Standard Time" (with
   abbreviation IST in en-IE)
   - the time in December in Ireland is called "Greenwich Mean Time" (with
   abbreviation GMT)

What exactly is incorrect about this?


Mark

On Fri, Feb 9, 2018 at 11:36 PM, Paul Eggert <eggert at cs.ucla.edu> wrote:

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20180211/e677e7cc/attachment.htm>


More information about the tz mailing list