This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Patch: java.util.Calendar


>>>>> "Jeff" == Jeff Sturm <jsturm@one-point.com> writes:

Jeff> Calendar.add() in libgcj doesn't behave as the JDK does.  This
Jeff> patch brings it closer.  It still not be 100% correct, but I'd
Jeff> like to see this working in 3.0 if possible.

It's not even close to correct these days :-(.  The more I look at it
the more dismayed I am.

Jeff> I have an incomplete Calendar test that passes libgcj with the
Jeff> patch below.  When I get a little more time I'll figure out how
Jeff> to get the tests into Mauve, which doesn't test Calendar yet.

With this patch the Mauve test still doesn't work for me.

I tracked down my particular failure to the use of localtime in
GregorianCalendar.computeFields.  What timezone are you in?  The
failure is timezone dependent.

I have a fix for this but it is fairly complex.  It is complex because
we don't implement GregorianCalendar.getActualMaximum and because
GregorianCalendar.add is a bit dumb: it uses set() which will invalidate
fields as it goes -- but after computeFields we want all the fields to
be set correctly.  Also GregorianCalendar.adjust doesn't properly account
for leap years anyway.

I looked only briefly at the Classpath implementation of
GregorianCalendar.  I don't really have time to do that now :-(.  In
some ways it is better.  I wish I had time to really delve into it.

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]