Let me try to summarize why the negative SAVE (Ireland change) matters to Java-based projects. there are two basic streams of code - old and new. The older OpenJDK time-zone code and ICU Java code both derive from the same original 20 year old source. The newer OpenJDK time-zone code derives indirectly from Joda-Time, which is still based on many principles from the older OpenJDK code. The ThreeTen-Backport project is an early version of the newer OpenJDK time-zone code. Thus, the vast majority of Java time-zone code is linked and follows a similar approach. The basic data stored is: - a "raw" offset that changes over time, also known as "standard" - a "daylight" offset that changes over time (either relative to the "raw" or absolute) - time-zone changes available from 1970 or earlier - only the *current* names of time-zones are available Some problems: 1) The older code has limits on the difference between the "raw" and "daylight" offset in `GregorianCalendar`. Specifically, the "DST_OFFSET" can only be from 0 to 2 hours. Negative SAVE values are not expected or supported. Note that the limits of 0 to 2 hours are publicly visible via the API `GregorianCalendar.getLeastMinimum()` and friends. 2) The current names of the time-zones is accessed via an array of a fixed order, roughly [long-std, short-std, long-daylight, short-daylight]. Whether the std or daylight text form should be returned is determined by a parameter - a boolean, named "daylight". The basic way this is determined is whether the offset and the"raw" offset are the same or not. This is also expressed in `TimeZone.inDaylightTime()` and `ZoneRules.isDaylightSavings()`, making any switch in the boolean user-visible. The problem here is that the Ireland change flips when the boolean is true from summer to winter. Whereas the content of the array has been stable for 20 years. In the problematic case I looked at, this means that the wrong textual description is returned. ie. in winter, the code has always accessed array elements 0 and 1, whereas if the boolean flag is swapped it will access elements 2 and 3. Remember that only the *current* names of the time-zones are available - so if the Ireland change happens, the time-zone name will necessarily be wrong either before the change occurs or after it. It is a similar problem as Yoshito Umaoka from CLDR expressed a clash between data and code. Here the data on names would clash with the boolean "daylight" flag. Fixing the code doesn't help in this scenario - there is no viable approach to fixing it that can work, as Java has a long history of backwards compatibility over decades, not a year (as is being talked about). Specifically, some of these libraries (Joda-Time, ThreeTen-Backport) run with new tzdb data on older JDK versions. It is the incompatibility in the boolean, where false no longer means winter that cannot be accepted. So, to summarize, even if those in the CLDR/ICU/Java world thought this change was meaningful and positive, backwards compatibility rules out making it. But, in fact the majority of the feedback on the topic from software library maintainers has been negative. I'm pretty sure that negative SAVE is going to be rejected by CLDR, ICU, OpenJDK, Joda-Time and ThreeTen-Backport permanently, and probably Android and Apple too based on their responses so far. As I've outlined, there is no way to meet the backwards compatibility requirements with it. A one year stay of execution won't make a difference in the practicality of the change. FWIW, I understand why some are attached to trying to express data in a "pure" form, but that was never the original intent of the project IMO. The project needs to get back to serving its downstream consumers who just want to know the time without continuous instability in the data format. Stephen PS, Microsoft .NET APIs also have an IsDaylightSavingTime() method: https://msdn.microsoft.com/en-us/library/bb460642(v=vs.110).aspx#Anchor_3