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#getDisplay...
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.