Java/OpenJDK is a different project from tzcode, and it has always supported a superset-of-a-subset of what tzcode supports. For example, Java (at least, Oracle's version of Java) does not support POSIX-format TZ settings; on the other hand, Java supports long names like "Pacific Standard Time" that tzcode does not. With that in mind, it would be understandable if Java/OpenJDK decides not to support negative DST offsets; it would be just one more thing in the list of things that tzcode has but Java lacks. If that happens, it should be possible for Java-based readers of tzdata source files to automatically translate negative DST offsets into positive ones (switching abbreviations of course), as I think Stephen Colebourne suggested. It's also possible that all things considered it would be better if Java supported negative
DST offsets -- but that's not our call to make.
I'm maintaining time zone data in CLDR and implementation in ICU. In ICU implementation, supporting negative DST offset in a new version is not difficult at all (only a few line of changes). A bigger problem is that we currently distribute only time zone data (in ICU consumable format) for updating older ICU releases. There are many ICU consumers who want the latest time zone data, but do not want to change anything else. Releasing a code patch for every past versions is a hassle for us too. I think Java folks are in the same situation.
We can give the Java folks some time to prepare for this by backing out the Irish changes for now. We can bring the changes back in the not-too-distant future, and in the meantime the Java folks can test their fixes on 2018b.
Java also imports time zone display name data from CLDR (BTW, CLDR uses "Irish Standard Time" as the long name). CLDR project cannot easily swap names for standard time and daylight saving time, because we also have many data consumers in various different implementations. Such change will definitely break our downstream consumers. I guess CLDR would just stay with the current (GMT as standard time, IST as daylight saving time) forever. In ICU, because we don't want to break ICU tz data backward compatibility, I decided to modify 2018a Europe/Dublin to swap standard time and daylight saving time, so we don't need to change localized display name data in many languages at least for now. Even ICU code is ready to support negative DST offsets, we may continue to swap standard/daylight for Europe/Dublin. -Yoshito Umaoka (Unicode CLDR/ICU)