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

Meno Hochschild mhochschild at gmx.de
Thu Jan 18 21:36:09 UTC 2018

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 

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 

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.


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.

More information about the tz mailing list