On 01/22/2018 09:19 AM, Stephen Colebourne wrote:
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.
By "older code" I assume you mean Java 8 and earlier, along with ICU Java code. Does newer Java code (Java 9, ThreeTen-Backport) also have these limitations? If so, this should probably be fixed in newer code regardless of the Irish time issue, as 0-2 hours is a pretty-restrictive limit and it's plausible that some government somewhere will go outside that window in the positive direction as well as in the negative.
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.
Why would that be the "wrong textual description"? If the data are changed so that Irish standard time is most of the year and winter time uses a negative DST offset, then [long-std, short-std, long-daylight, short-daylight] will be ["Irish Standard Time", "IST", "Greenwich Mean Time", "GMT"] and it will be correct to access elements 2 and 3 in winter.
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.
I'm not quite following as some details are omitted in your summary, but isn't it possible that the traditional behavior gets old Irish timestamps wrong that the proposed behavior will fix? If I understand you correctly then with the old approach (in 2017c, say), Java code mishandles Irish time stamps from 1968 to 1971 because they use Irish Standard Time (IST) and are at UTC+01 with tm_isdst==0, but Java calls them "Greenwich Mean Time" or "GMT" because their DST offset is zero. In contrast, the proposed behavior should cause new Java code to correctly call them "Irish Standard Time" or "IST".
I'm pretty sure that negative SAVE is going to be rejected by CLDR, ICU, OpenJDK, Joda-Time and ThreeTen-Backport permanently That's too bad, as there doesn't seem to be any significant technical reason (other than inertia) as to why Java code couldn't support negative DST in the future. This feature has been supported in tzcode and in other downstream implementations for decades, and it's easy to support.
That being said, we do need a way to support implementations that don't support negative DST as well as those that do, and I'll look into doing that after 2018c comes out.