[tz] OpenJDK/CLDR/ICU/Joda issues with Ireland change

Stephen Colebourne scolebourne at joda.org
Mon Jan 22 18:47:07 UTC 2018


On 22 January 2018 at 18:16, Paul Eggert <eggert at 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


More information about the tz mailing list