Bug in Calendar when setting time across daylight-saving boundaries?!

Tue Oct 5 08:36:00 GMT 2004

Hi Bryce,
> I took a quick look at this. On mainline I do not see a problem with 
> day-of-month changing, so I guess this has already been fixed - probably 
> with Mark Wielaard's recent Calendar improvements.
Yes, sorry this was actually only seen on 3.3.3...
> I did see the problem with the hour-of-day being wrong. The problem here 
> is that Calendar.set does not invalidate the DST_OFFSET field even 
> though changing other fields could roll the time over a DST boundary. 
> Thus, computeTime() applies the DST offset to the resulting Date value 
> even if the date is no longer in a DST period.
> This patch below should fix the problem. I haven't yet tested this 
> extensively. Could you submit a mauve regression test, based on your 
> test case?
I haven't look into mauve regression tests at all, so I didn't run your 
patch against it - yet!
However, I tested it back and forth, and it seems to work as is 
supposed, perfect!
The only thing it stumbled across is the (known) bug in SimpleTimeZone 
regarding configuring the dst-start and end-time like:
 SimpleTimeZone stz = new SimpleTimeZone(60 * 60 * 1000, "MyZone",
 Calendar.MARCH, -1, Calendar.SUNDAY, 2 * 60 * 60 * 1000,
 Calendar.OCTOBER, -1, Calendar.SUNDAY, 2 * 60 * 60 * 1000);
which will make the day of change the first sunday in both march and 
october instead of the last. However, this should have been fixed in 
cvs, I reckon...
So, with these two bugs fixed, the Calendar works as supposed :o)
When do you think these will make it into a stable branch? 3.4.3 or 4.0.0?
Thanks for your help!
 Martin
> * java/util/Calendar.java (set): Invalidate DST_OFFSET as setting a
> calendar field may roll over a DST boundary.
>> --- Calendar.java 29 Aug 2004 17:28:09 -0000 1.23
> +++ Calendar.java 4 Oct 2004 22:02:42 -0000
> @@ -651,6 +651,10 @@
> isSet[HOUR_OF_DAY] = false;
> break;
> }
> + + // We may have rolled over a DST boundary.
> + if (field != DST_OFFSET && field != ZONE_OFFSET)
> + isSet[DST_OFFSET] = false;
> }