[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DST related Calendar regression
From: |
Noa Resare |
Subject: |
Re: DST related Calendar regression |
Date: |
Fri, 05 Nov 2004 15:30:06 +0100 |
tis 2004-11-02 klockan 10:36 -0500 skrev Bryce McKinlay:
> 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:
I think that treating DST_OFFSET and ZONE_OFFSET as read only is
reasonable, and marginally better than the current solution, but
please don't silently ignore any attempts to set DST_OFFSET. If we
choose not to use the provided value as expected by for example
SimpleDateFormat the only reasonable thing to do IMO is to throw an
exception.
This is a case when we change our behavior and where the spec is vague.
Users depending on the old classpath behavior deserves at least an
exception and fast failure.
I'll probably write a patch that does this as you suggest tonight. Stay
tuned :)
/noa