This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: Patch: java.util.Calendar
- To: Jeff Sturm <jsturm at one-point dot com>
- Subject: Re: Patch: java.util.Calendar
- From: Tom Tromey <tromey at redhat dot com>
- Date: 26 Apr 2001 18:56:07 -0600
- Cc: java-patches at gcc dot gnu dot org
- References: <Pine.LNX.4.10.10104251626360.18135-100000@mars.deadcafe.org>
- Reply-To: tromey at redhat dot com
>>>>> "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