DST related Calendar regression

[Noa Resare]

On 04-10-08 address@hidden 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.

A concrete example of this is when you use a SimpleDateFormat to parse a
date with timezone information. Under certain circumstances[1] the
underlying Calendar uses the current TimeZone for DST info instead of
the information provided in the date to be parsed.

The real problem here is that there are two ways of specifying timezone
information, either by Calendar.setTimeZone() or by setting DST_OFFSET
and ZONE_OFFSET with Calendar.set(). When these two pieces of
information are in conflict we need to determine which one to use.

The attached patch implements a behavior when the value of DST_OFFSET is
calculated as a function of the value of getTimeZone() and the current
time except when the user explicitly sets DST_OFFSET. In that case the
value of DST_OFFSET overrides the value derived from the timezone. 

The patch doesn't have any mauve regressions as verified by my testdiff
[2] tool.

/noa

ps. This also fixes DateFormatTest regression in kaffe.

1) the last test in mauve gnu/testlet/java/text/SimpleDateFormat/regress
2) http://resare.com/noa/testdiff/

classpath-calendar.patch
Description: Text Data