libgcj/2641: Calendar and GregorianCalendar have serious problems

[Warren Levy]

On 25 Apr 2001 tromey@redhat.com wrote:

> >Description:
> The Calendar and GregorianCalendar implementations
> in libgcj have serious problems.  Neither handles
> rollover or leniency correctly.  Also,
> GregorianCalendar.computeTime does not properly check
> isSet on fields; nor does it follow the spec on the
> order in which fields ought to be checked (see the JCL
> book for details on this).

Tom, thanks for filing this bug.  I've been remiss by not filing a PR for
the areas where work is still needed (I did try to mark the code with
FIXME's, but not always consistently :-( ).

You're right about the leniency/rollover issues.  Until recently they
weren't handled at all.  My changes relied on mktime() to handle that but
I suspect that there are some cases where mktime() handles normalization
differently than the JCL documents.

Note that regarding the order fields are checked, the JCL has been
overridden in the JCL supplement (i.e. JDK 1.2).  In JDK 1.2, much of the
calculation is based on an (undocumented) internal timestamp for the
fields where a more recently changed field has precedence over other
changed fields.  There are ambiguous cases though (touched on in the JCL
supplement) that still resort to the precedence order.

FWIW, I think Jeff Sturm's isSet fields changes posted in his recent patch
are necessary.  Another change I suspect is necessary when implementing
either the timestamp or order precedence changes is to remove:

    if (!areFieldsSet)
      computeFields();

from the set(int field, int value) and set(int year, int month, int date)
methods of Calendar.  From my reading of the doc, that shouldn't be done.
At the least it is a waste of resources.  Without the timestamp code or
precedence code, it was not problematic though.  At one point I was going
to take it out but couldn't prove to myself at the time that removing it
didn't have some other side-effect that needed to be addressed (so I left
it in).  My bad on not marking that with a FIXME to remove it when
timestamp/precedence code is implemented.
--warrenl