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.