Noa Resare wrote:
On 04-10-08 [EMAIL PROTECTED] 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
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
