<tt><font size=2>> Java/OpenJDK is a different project from tzcode,

and it has always <br>> supported a superset-of-a-subset of what tzcode supports. For example,

<br>> Java (at least, Oracle's version of Java) does not support POSIX-format

<br>> TZ settings; on the other hand, Java supports long names like "Pacific

<br>> Standard Time" that tzcode does not. With that in mind, it would

be <br>> understandable if Java/OpenJDK decides not to support negative DST

<br>> offsets; it would be just one more thing in the list of things that

<br>> tzcode has but Java lacks. If that happens, it should be possible

for <br>> Java-based readers of tzdata source files to automatically translate

<br>> negative DST offsets into positive ones (switching abbreviations of

<br>> course), as I think Stephen Colebourne suggested. It's also possible

<br>> that all things considered it would be better if Java supported negative

<br>> DST offsets -- but that's not our call to make.<br>> <br></font></tt><br><tt><font size=2>I'm maintaining time zone data in CLDR and implementation

in ICU.</font></tt><br><br><tt><font size=2>In ICU implementation, supporting negative DST offset

in a new version</font></tt><br><tt><font size=2>is not difficult at all (only a few line of changes).</font></tt><br><br><tt><font size=2>A bigger problem is that we currently distribute only

time zone data</font></tt><br><tt><font size=2>(in ICU consumable format) for updating older ICU

releases. There are</font></tt><br><tt><font size=2>many ICU consumers who want the latest time zone data,

but do not want</font></tt><br><tt><font size=2>to change anything else. Releasing a code patch for

every past versions</font></tt><br><tt><font size=2>is a hassle for us too. I think Java folks are in

the same situation.</font></tt><br><br><br><tt><font size=2>> We can give the Java folks some time to prepare

for this by backing out <br>> the Irish changes for now. We can bring the changes back in the <br>> not-too-distant future, and in the meantime the Java folks can test

<br>> their fixes on 2018b.<br>> </font></tt><br><br><tt><font size=2>Java also imports time zone display name data from

CLDR (BTW, CLDR uses</tt> <tt><font size=2>"Irish Standard Time" as the long name).

CLDR project cannot easily</tt> <tt><font size=2>swap names for standard time and daylight saving time,

because we also</tt> <tt><font size=2>have many data consumers in various different implementations.

Such</tt> <tt><font size=2>change will definitely break our downstream consumers.

I guess CLDR</font></tt><br><tt><font size=2>would just stay with the current (GMT as standard

time, IST as daylight</font></tt><br><tt><font size=2>saving time) forever.</font></tt><br><br><tt><font size=2>In ICU, because we don't want to break ICU tz data

backward compatibility,</font></tt><br><tt><font size=2>I decided to modify 2018a Europe/Dublin to swap standard

time and</font></tt><br><tt><font size=2>daylight saving time, so we don't need to change localized

display name</font></tt><br><tt><font size=2>data in many languages at least for now. Even ICU

code is ready to support</font></tt><br><tt><font size=2>negative DST offsets, we may continue to swap standard/daylight

for</font></tt><br><tt><font size=2>Europe/Dublin.</font></tt><br><br><tt><font size=2>-Yoshito Umaoka (Unicode CLDR/ICU)</font></tt><br><BR>