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 _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
