[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