Re: DST related Calendar regression

[Bryce McKinlay]

Noa Resare wrote:

> On 04-10-08 address@hidden checked in changes to java.util.Calendar
> that effectively made an explicitly set DST_OFFSET value to a function
> of the set TimeZone for the Calendar object if an other field (such as
> YEAR) is set in the calendar after DST_OFFSET is set.
>
> I think this is wrong, as someone who sets DST_OFFSET explicitly and not
> via .setTimeZone() presumably knows what she is doing and expects the
> provided DST_OFFSET to be used.
>  
Hi Noa,

Thanks for looking into this. I agree that there is a bug here, as 
demonstrated by your mauve test, but I'm not sure that this is the 
correct fix. It should not be possible to set DST_OFFSET explicitly 
because DST_OFFSET changes at different times of the year depending on 
whether the Calendar is in DST or not according to the rules of it's 
TimeZone. ie: for a given timezone and date value, there is only one 
valid value for the DST_OFFSET field and it doesn't make sense to set a 
different one explicitly.

Although the spec doesn't define what happens if you do this, I think 
the simplest (implementation-wise) and most logical approach is to 
ignore user attempts to set DST_OFFSET, which also appears to be what 
Sun's implementation does (recent ones, at least). Consider the 
following test case for an example:

import java.util.*;

public class TestDST
{
 public static void main(String[] args)
 {
   Calendar c = 
Calendar.getInstance(TimeZone.getTimeZone("America/Toronto"));
   c.set(2004, Calendar.NOVEMBER, 1);  // Not in DST period
   c.set(Calendar.DST_OFFSET, -10000);
   System.out.println (c.get(Calendar.DST_OFFSET));

   c.set(2004, Calendar.OCTOBER, 1);  // In DST period
   c.set(Calendar.DST_OFFSET, 0);
   System.out.println (c.get(Calendar.DST_OFFSET));
 }
}

With Sun's JDK 1.5, this gives the following output:

$ java TestDST
0
3600000

So, I think the real bug here is in SimpleDateFormat - it should only 
use setTimeZone() and not try to set DST_OFFSET or ZONE_OFFSET 
explicitly. We should clarify our Javadoc to specify that attempts to 
set these fields explicitly are ignored.

Regards

Bryce