Re: [patch] merge Calendar/Date fixes from classpath

[Bryce McKinlay <mckinlay at redhat dot com>]

Andreas Tobler wrote:

> Hi all,
>
> another one. Ok if no regressions from mauve?
>
> Andreas
>
> 2004-11-15  Andreas Tobler  <a.tobler@schweiz.ch>
>
>     Merge Calendar/Date fixes from Classpath:
>
>     2004-10-31  Noa Resare  <noa@resare.com>
>
>     * java/util/Calendar.java (explicitDSTOffset): New instance field.
>     (set(int,int)): Set and use new field.
>     (set(int,int,int)): Check new field.


IMO, this one is wrong and should be reverted in favour of a different 
solution. See this thread: 
http://lists.gnu.org/archive/html/classpath/2004-11/msg00004.html

>     2004-10-17  Jeroen Frijters  <jeroen@frijters.net>
>
>     * java/util/Calendar.java (setTimeInMillis): Added call to clear,
>     removed computeFields call.
>     * java/util/Date.java (Date(int,int,int,int,int,int)): Removed
>     workaround for GregorianCalendar bug.
>     * java/util/GregorianCalendar.java (GregorianCalendar): Chained all
>     constructors to a (new) common constructor.
>     (computeTime): Fixed support for lenient month treatment.
>     (getLinearDay): Return long instead of int.
>     (calculateDay): Added fields argument and changed day argument
>     to long.


This one introduces a pretty serious performance regression - we now 
allocate an array whenever the time is computed, which in some cases can 
mean every time a calendar field is set/updated. I think there's a 
better way to fix this, too, but it does require a bit of work. See: 
http://lists.gnu.org/archive/html/classpath/2004-10/msg00139.html

Nevertheless, although these fixes arn't optimal, they do fix bugs, so 
perhaps its better to keep in sync with classpath for now, until someone 
gets around to fixing Calendar properly.

Bryce