Re: DST related Calendar regression

[Noa Resare]

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