[tz] Irish Standard Time vs Irish Summer Time

[Stephen Colebourne]

For those not paying full attention, this patch did not revert all of
the changes! Instead it effectively disabled the negative SAVE value
in the "Rule" section by not using it from the "Zone" section.

I have investigated the impact of negative SAVE values on
ThreeTen-Backport - http://www.threeten.org/threetenbp/ - which is
basically a forked version of some of the OpenJDK code. The good news
is that the data files are still parsed and timestamps are still
correct. The bad news is that negative SAVE values completely screw up
Java APIs that have existed for 20 years.

ThreeTen-Backport and OpenJDK have the methods:

 ZoneRules.isDaylightSavings(Instant)
 ZoneRules.getDaylightSavings(Instant)
https://docs.oracle.com/javase/8/docs/api/java/time/zone/ZoneRules.html#getDaylightSavings-java.time.Instant-

With the Irish changes, the former method now returns true in winter
and false in summer. And the latter returns a negative offset in
winter and zero in summer.

The problem is that there is lots of underlying code in other parts of
the JDK (which can't be changed as its been that way for 20 years)
that takes a DST boolean flag:

 TimeZone.getDisplayName(boolean daylight, int style, Locale locale)
https://docs.oracle.com/javase/8/docs/api/java/util/TimeZone.html#getDisplayName-boolean-int-java.util.Locale-

This method has expected the daylight flag to be true in summer and
false in winter for 20 years.

It is simply not possible to take the new DST true/false flag and
negate it to call this method only in the case where there is a
negative SAVE value (I've tried - the problem is that you don't know
if it is negative SAVE if the instant you are given is in the summer).

Given that it will be impossible to make the code work with negative
offsets, the only solution is to change the parser to reverse negative
offsets back to positive ones. This will continue to meet the
expectation of the vast majority of users that DST means a more
forward in summer. (Not doing this will just result in bug reports
where users complain that isDaylightSavings() is returning true in
winter).

As such, I believe that negative SAVE values should be removed
permanently from tzdb and explicitly banned. The timestamps can always
be represented the other way around, and the meaning of the
abbreviation wrt which is "standard" is not the concern of tzdb anyway
(which should be focussed on telling the time).

Stephen



On 19 January 2018 at 08:14, Paul Eggert <eggert at cs.ucla.edu> wrote:
> Philip Paeps wrote:
>>
>> Given the number of things this break, I would suggest backing the change
>> out for now but pointing out in NEWS that it will come back say one year
>> from now.
>>
>> Replace the actual change by a comment that the current data is inaccurate
>> pending software being fixed.
>
>
> Thanks, this sounds like a good way to go. Proposed patch attached, and
> installed into the development version on GitHub. Presumably there should be
> a 2018c release quite soon, to get this temporary workaround out the door.
> (2018b has been prepared and published but not announced, since the problems
> with ICU and OpenJDK became apparent during the post-publication process.)
>
> There is a conflict between the goals of "let's not break anything" and
> "let's match civil timekeeping practice". I lean towards doing the latter as
> long as it doesn't cause too much trouble for the former. Here it seems like
> there is some trouble with ICU and OpenJDK, so delay seems advisable until
> fixes can be prepared. That being said, I don't want to wait indefinitely
> for these fixes. This is not a tzdb-specific issue, since POSIX requires
> support for negative DST (e.g., TZ='IST-1GMT0,M10.5.0,M3.5.0/1' for current
> Irish rules), which means that applications that reject negative DST are not
> portable to standard platforms configured for Irish time.
>
> The proposed patch continues to use the "IST is standard time" approach for
> Irish timestamps between October 1968 and October 1971, but I assume that's
> OK since that's what we did before.