[tz] [english 100%] Re: OpenJDK/CLDR/ICU/Joda issues with Ireland change

Robert Elz kre at munnari.OZ.AU
Sun Jan 28 06:07:55 UTC 2018


  From: Meno Hochschild <mhochschild at gmx.de>
  Date: Sun, 28 Jan 2018 05:17:37 +0100
  Subject: Re: [tz] [english 100%] Re: OpenJDK/CLDR/ICU/Joda issues with
    Ireland change

  | Here stable documented keys and values are important, of course.

The key only exists to allow for some other (currently unknown) data to
be added in a similar way sometime in the future, doing it that way might
be a good idea, or if we cannot think of anything else we're likely to
want to add, it could just be omitted.   If it exists, then yes, for this
purpose its value would be set in stone, and never change.

The values, however, not so much - what would be needed are agreed values
with CLDR for CLDR to use - but from time to time we'd need to be able
to add new ones (and like everything else time related, sometimes very
quickly - so long grace periods are not always possible, however desirable
they might be).    I would assume that you could handle that by simply
advising those who use the data to use the numeric offset (converted to
a string) if one of these values is not found (if new tzdata has added a
new one, and updated CLDR has not been released with the appropriate new
data added yet).

I would suggest not using 1 char values however (at least, not generally)
or someone will start assuming they always must be, and complain when
a longer one appears!  Just allow for arbitrary non-whitespace strings
(perhaps alphanumeric (and _) only to avoid someone deciding that "X>"
would be nice to use).

  | The new file can be safely ignored 
  | by zic but help other tz-compilers to easily determine localized labels 
  | of timezones in unchanged CLDR-entries.

  | I just try to find a compromise with minimalistic impact on all sides.

I would not worry about any of that yet - first order of business should
be working out what is needed - what data would be useful for tzdata to
make available that would allow CLDR, and then its clients, to operate
better, and without assumptions.  Once we know that, we can work out how
best to implement it, and how to make the results visible.  Those are
much less important right now.

There is no huge urgency here, we have time to do it properly.

kre


More information about the tz mailing list