[tz] Irish Standard Time vs Irish Summer Time
Paul Eggert
eggert at cs.ucla.edu
Fri Jan 19 19:04:26 UTC 2018
On 01/19/2018 03:16 AM, Stephen Colebourne wrote:
> 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.
In what sense does the method "expect" DST to be true in Irish summer
and false in Irish winter? That is, what exactly goes wrong if that
expectation is not met? Can you illustrate the problem with a small Java
application that breaks if Java treats Irish Standard Time as standard time?
(A minor point of terminology: at bottom, this is an issue about
negative DST offsets, not about whether DST is observed in summer or
winter. For example, for America/Boa_Vista the daylight flag is true in
winter and false in summer for timestamps through the year 2000, but I
doubt whether any Java apps care because the DST offset was positive in
Boa Vista during that period.)
> 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 don't see why that would be needed. The DST boolean can continue to
say whether DST is in effect, just as before.
> Given that it will be impossible to make the code work with negative
> offsets,
I don't see where the Java API disallows negative DST offsets. For
example, in Oracle Java 9.0.4, TimeZone.getDSTSavings returns an 'int',
and this allows for negative offsets.
So far, we've seen failures only in Java test suites, which aren't a
major concern. What will be the effect on Java applications? That's the
more important question.
More information about the tz
mailing list