[tz] [english 100%] Re: Irish Standard Time vs Irish Summer Time

[Meno Hochschild]

Well, I am not astonished to see problems elsewhere with negative dst 
offset. About ICU4J, I am not sure but assume that they parse the source 
files.

And about Java/OpenJDK which parses the source files, too: There is at 
least one issue reported => https://bugs.openjdk.java.net/browse/JDK-8195595

After having looked at the official Java source code of a 
timezone-method for determining if there is daylight or winter time at a 
given instant, I also suspect that this is another problem (not yet 
tested): Java would start with v2018a to report Irish Summer Time (IST) 
in winter and GMT in summer when it comes to formatting the Irish zone 
Europe/Dublin.

By the way, my lib Time4J which parses the tz-sources to compile a 
distribution would have crashed if I had not watched this mailing list 
and prepared for the Ireland case in 2018a. And the necessary compiler 
and tzdata changes were not so trivial because I had also to care about 
the winter/summer-format described before.

Meno


Am 18.01.2018 um 21:24 schrieb Paul Eggert:
> On 01/18/2018 11:40 AM, Deborah Goldsmith wrote:
>
>> currently-shipping versions of ICU cannot deal with negative DST 
>> offsets; they will refuse to accept the data (illegal argument error).
>
> Could you give more details? Is the problem with code that reads tzdb 
> source files, or with code that reads binary files produced by zic? 
> How can I reproduce the problem from the ICU source code? Is there a 
> publicly-available bug report about the problem? (I looked for one in 
> <http://bugs.icu-project.org/trac/wiki/IncomingBugs> and couldn't find 
> it.) That sort of thing.
>
> I'm asking for these details because there may be a way to implement 
> Irish standard time while avoiding the specific problem that the ICU 
> code is running into.
>
>> Would it be possible to roll this change out and plan to reintroduce 
>> it in the future, along with the changes needed in ICU and CLDR? (As 
>> well as a plan to deploy the updated ICU/CLDR to the field). I would 
>> also be OK with just backing it out period, but if we’re going to 
>> keep this change we need time for ICU and CLDR to adjust.
>
> If the problem is serious enough and cannot be worked around, we could 
> back out the change in the next tzdb release and then re-add the 
> change later, once things have settled down.
>
> I'm concerned as to why this problem wasn't discovered until now. The 
> change for Ireland has been in the development repository since 
> December 7 and was circulated for comments, and the only specific 
> problem reported for it was so trivial that it was not worth worrying 
> about. If ICU depends in crucial ways on undocumented properties of 
> tzdb, then ICU maintainers need to monitor this mailing list and/or 
> run tests based on the development repository, and do that on a 
> regular basis. Otherwise further problems like this will be inevitable.
>
>