[tz] [english 100%] Re: [english 100%] Re: OpenJDK/CLDR/ICU/Joda issues with Irelandchange
Meno Hochschild
mhochschild at gmx.de
Fri Jan 26 04:49:44 UTC 2018
An illustrating example: If the rule line contains an optional
meta-column at the end whose content is a key-value-structure
(comma-separated in case of several entries for any other purpose) then
the Eire-rules might look like this:
# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S META
Rule Eire 1971 only - Oct 31 2:00u -1:00 GMT category=winter
Rule Eire 1972 1980 - Mar Sun>=16 2:00u 0 IST category=summer
If the new META-column is missing at all or if its content does not
contain an entry with key "category" (you are free to use a better key)
then other tzdb-source-file consumers like Java or ICU are free to
continue the assumption that winter time is to be determined by
evaluating SAVE = 0 (current practice). Note that these consumers cannot
evalute the column LETTERS/S as that column has no clear stable keys
("IST" would be specific for Ireland only and does not enable a general
evaluation if it is connected to summer period).
Then:
After such a change, a source-file-tzdb-compiler can use this new
information to determine the right entry in CLDR-data. If the value of
key "category" is "winter" then use the CLDR-entry <standard>Greenwich
Mean Time</standard> for getting the right time zone name (we leave out
here the fact that CLDR does not support historized tz names but that is
another problem not really related to this topic). If the value of key
"category" is "summer" then use the alternate CLDR-entry <dailight>Irish
Standard Time</daylight>. The new source format enhancement of tzdb only
needs to be documented and should use standardized values like "winter",
"summer" (or even "ramadan").
This way, CLDR-data don't even need to be changed at all so it is
completely backwards compatible. The ICU- and Java-compilers would need
a grace period to adjust their compilers and their own binary tz-format
to process the new available informations (which should be not so
difficult). If ICU or OpenJDK (Java) are still unwilling to change their
current implementation then introducing negative dst offsets will
inevitably break the way they determine the right tz label (resulting in
"Irish Standard Time" in winter). But it would be their problem and
responsibility. IMHO downstream consumers should be flexible and are
expected to be flexible if they get the chance to fix their products
after having got new informations in the tzdb source file format.
I have adjusted my tzdb-compiler (Time4J) such that it looks if all rule
lines referencing the same name (here: Eire) contain any negative dst
offsets. If yes then let's assume summer time for SAVE=0 and winter time
for SAVE < 0. So I can still work with old unchanged CLDR-entries for
getting "Irish Standard Time" in summer. Although I am not quite sure if
this way of fixing is stable enough for the future it demonstrates that
it is possible for downstream consumers to cope with negative dst
offsets already now. My proposal serves for making the handling of
negative dst offsets easier and more stable. If any downstream consumers
are still unwilling to handle negative dst offsets then it is just
laziness for me.
With best regards
Meno
Am 25.01.2018 um 22:53 schrieb Paul Eggert:
> I'm afraid that I'm not understanding the proposal; could you write up
> Irish time as a specific example to help explain it? Remember, the
> problem is not whether Java can be changed to support negative DST
> offsets (or, for that matter, whether it can be changed to support the
> new feature you're proposing). The problem is how to transition from
> the old to the proposed system without breaking anything significant,
> even when some components are old and some are new.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20180126/6ddc18cf/attachment.htm>
More information about the tz
mailing list