On 22 January 2018 at 18:16, Paul Eggert <eggert@cs.ucla.edu> wrote:
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. Yes
Does newer Java code (Java 9, ThreeTen-Backport) also have these limitations? No. The biggest limit is that offsets are constrained to -18 to +18 hours.
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.
This will happen in the perfect scenario where everything is updated at once. The problem is that the perfect scenario is the anomaly. In many perfectly reasonable scenarios, one will be updated without the other being updated, causing nonsense output. Switching the meaning of a boolean flag is like doing a U-turn on a freeway. Fine if everyone else does the U-turn at the same instant as you, but if not you'll get flattened by the truck behind you. So, this simply isn't like zic and the OS sitting at the bottom of the stack. Those objecting live higher in the stack where different projects/data get updated at different speeds, and thus we really, really care about keeping things stable.
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.
To paraphrase your response, thats too bad, as there doesn't seem to be any good reason (other than a misguided notion of purity) as to why TZDB should be changed at all. Moreover, having the operating system (via zic) run on different rules to the applications that run it seems destined to end in tears. As per Arthur Olson's recent email - TZDB has grown far beyond the data and zic. There are many many consumers of the data collected here. Proceeding with this change, * in any form*, is unwise and unhealthy for the project given how much opposition there clearly is (and how little support). Stephen