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

[Meno Hochschild]

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