Re: [kaffe] Re: GregorianCalendar fixes
Hi, >>>>> ":" == Mark Wielaard <[EMAIL PROTECTED]> writes: :> There is only one functional change left between kaffe and classpath in :> computeFields(): :> -fields[DAY_OF_WEEK_IN_MONTH] = (fields[DAY_OF_MONTH] + 12) / 7; :> +fields[DAY_OF_WEEK_IN_MONTH] = (fields[DAY_OF_MONTH] + 6) / 7; :> Haven't looked at who is right here, so won't merge. This change about DAY_OF_WEEK_IN_MONTH was in Mark's patch [1] (see below) but was not in my original patch [2] (see below) posted to the kaffe mailing list. This patch seemes to have been introduced by analogy with the patch about WEEK_OF_MONTH. But Sun's API document says: Unlike WEEK_OF_MONTH and WEEK_OF_YEAR, this field's value does not depend on getFirstDayOfWeek() or getMinimalDaysInFirstWeek(). DAY_OF_MONTH 1 through 7 always correspond to DAY_OF_WEEK_IN_MONTH 1; 8 through 14 correspond to DAY_OF_WEEK_IN_MONTH 2, and so on. In this respect, fields[DAY_OF_WEEK_IN_MONTH] = (fields[DAY_OF_MONTH] + 6) / 7; seems to be correct. [1] From: Mark Wielaard <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Message-Id: <[EMAIL PROTECTED]> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 21 Nov 2003 17:14:35 +0100 Cc: [EMAIL PROTECTED] Subject: GregorianCalendar fixes X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.1.2 List-Unsubscribe: <http://mail.gnu.org/mailman/listinfo/classpath>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://mail.gnu.org/pipermail/classpath> List-Post: <mailto:[EMAIL PROTECTED]> List-Help: <mailto:[EMAIL PROTECTED]> List-Subscribe: <http://mail.gnu.org/mailman/listinfo/classpath>, <mailto:[EMAIL PROTECTED]> [1 ] [1.1 ] [1.1.1 ] Hi, Since I am not a GregorianCalendar expert I was hoping that someone could review the following patch which I have in my tree from Ito Kazumitsu. He and I wrote a couple of mauve test cases which are fixed by this and I see no new failures. But people didn't seem to be completely comfortable with it back in Augustus/September. It would be nice if we could create even more test cases to make sure that nothing else breaks and to have a ChangeLog entry for this patch (Ito?). Don't really have have time to learn about Calendars so I am just re-posting this patch in the hope that someone can review it. Thanks, Mark [1.1.2 GregorianCalendar.patch ] Index: java/util/GregorianCalendar.java === RCS file: /cvsroot/classpath/classpath/java/util/GregorianCalendar.java,v retrieving revision 1.20 diff -u -r1.20 GregorianCalendar.java --- java/util/GregorianCalendar.java12 Aug 2003 13:41:27 - 1.20 +++ java/util/GregorianCalendar.java21 Nov 2003 16:11:56 - @@ -1,5 +1,5 @@ /* java.util.GregorianCalendar - Copyright (C) 1998, 1999, 2001, 2002 Free Software Foundation, Inc. + Copyright (C) 1998, 1999, 2001, 2002, 2003 Free Software Foundation, Inc. This file is part of GNU Classpath. @@ -264,8 +264,10 @@ // // The additional leap year factor accounts for the fact that // a leap day is not seen on Jan 1 of the leap year. + // And on and after the leap day, the leap day has already been + // included in dayOfYear. int gregOffset = (year / 400) - (year / 100) + 2; - if (isLeapYear (year, true) && dayOfYear < 31 + 29) + if (isLeapYear (year, true)) --gregOffset; time += gregOffset * (24 * 60 * 60 * 1000L); } @@ -604,12 +606,12 @@ calculateDay(++day, gregorian); } -fields[DAY_OF_WEEK_IN_MONTH] = (fields[DAY_OF_MONTH] + 6) / 7; +fields[DAY_OF_WEEK_IN_MONTH] = (fields[DAY_OF_MONTH] + 12) / 7; // which day of the week are we (0..6), relative to getFirstDayOfWeek int relativeWeekday = (7 + fields[DAY_OF_WEEK] - getFirstDayOfWeek()) % 7; -fields[WEEK_OF_MONTH] = (fields[DAY_OF_MONTH] - relativeWeekday + 6) / 7; +fields[WEEK_OF_MONTH] = (fields[DAY_OF_MONTH] - relativeWeekday + 12) / 7; int weekOfYear = (fields[DAY_OF_YEAR] - relativeWeekday + 6) / 7; [1.2 This is a digitally signed message part ] [2 ] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath [2]= From: Ito Kazumitsu <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] In-reply-to: Ito Kazumitsu's message of "Mon, 28 Jul 2003 10:46:11 +0900" <[EMAIL PROTECTED]> Subject: Re: [kaffe] Bug in Kaffe 1.0.7 User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (UnebigoryĆmae) APEL/10.3 Emacs/20.7 (i386-*-windows98.) MULE/4.1 (AOI) Meadow/1.14 (AWSAKA:62) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") X-BeenThere: [
Re: GregorianCalendar fixes
Hi, On Sat, 2003-11-29 at 20:15, Dalibor Topic wrote: > after the discussion on the Classpath mailing list, I'd say it looks good ;) > > Mark, can I check it into Classpath's CVS with an updated ChangeLog entry? I'll check this in while I am resyncing with kaffe. There is only one functional change left between kaffe and classpath in computeFields(): @@ -606,7 +611,7 @@ calculateDay(++day, gregorian); } -fields[DAY_OF_WEEK_IN_MONTH] = (fields[DAY_OF_MONTH] + 12) / 7; +fields[DAY_OF_WEEK_IN_MONTH] = (fields[DAY_OF_MONTH] + 6) / 7; // which day of the week are we (0..6), relative to getFirstDayOfWeek int relativeWeekday = (7 + fields[DAY_OF_WEEK] - getFirstDayOfWeek()) % 7; Haven't looked at who is right here, so won't merge. > 2003-11-29 Guilhem Lavaux <[EMAIL PROTECTED]> > > * java/util/GregorianCalendar.java (computeTime): > 12:00 midnight is AM and 12:00 noon is PM. > [...] > > --- java/util/GregorianCalendar.java.orig Thu Nov 27 15:35:08 2003 > > +++ java/util/GregorianCalendar.javaThu Nov 27 15:48:25 2003 > > @@ -402,7 +402,11 @@ > >{ > > hour = fields[HOUR]; > > if (isSet[AM_PM] && fields[AM_PM] == PM) > > - hour += 12; > > + if (hour != 12) /* not Noon */ > > +hour += 12; > > + /* Fix the problem of the status of 12:00 AM (midnight). */ > > + if (isSet[AM_PM] && fields[AM_PM] == AM && hour == 12) > > + hour = 0; > >} > > > > int minute = isSet[MINUTE] ? fields[MINUTE] : 0; Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: GregorianCalendar fixes
Hi Ito, after the discussion on the Classpath mailing list, I'd say it looks good ;) Mark, can I check it into Classpath's CVS with an updated ChangeLog entry? 2003-11-29 Guilhem Lavaux <[EMAIL PROTECTED]> * java/util/GregorianCalendar.java (computeTime): 12:00 midnight is AM and 12:00 noon is PM. cheers, dalibor topic Ito Kazumitsu wrote: Hi, ":" == Mark Wielaard <[EMAIL PROTECTED]> writes: :> Looked some more at the code and I see now that the the first change was :> inside a if (time >= gregorianCutover) so it now makes more sense to me. :> And the second change seems correct given the above remark. :> I'll commit it in Classpath. There is another difference between GNU Classpath's java/util/GregorianCalendar.java and that of kaffe. Kaffe's was imported from GNU Classpath and modified in the kaffe world, as described by the following ChangeLog entry. 2003-08-16 Guilhem Lavaux <[EMAIL PROTECTED]> * java/util/GregorianCalendar.java (computeTime): 12:00 midnight is AM and 12:00 noon is PM. Here is the patch that can be applied to Revision 1.21: --- java/util/GregorianCalendar.java.orig Thu Nov 27 15:35:08 2003 +++ java/util/GregorianCalendar.java Thu Nov 27 15:48:25 2003 @@ -402,7 +402,11 @@ { hour = fields[HOUR]; if (isSet[AM_PM] && fields[AM_PM] == PM) - hour += 12; + if (hour != 12) /* not Noon */ +hour += 12; + /* Fix the problem of the status of 12:00 AM (midnight). */ + if (isSet[AM_PM] && fields[AM_PM] == AM && hour == 12) + hour = 0; } int minute = isSet[MINUTE] ? fields[MINUTE] : 0; ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: GregorianCalendar fixes
Hi, > ":" == Stephen Crawley <[EMAIL PROTECTED]> writes: :> If Sun's implementation (you don't say which JDK version!) is failing :> a test, then that casts serious doubt on the correctness of the mauve :> testcase itself! I mentioned the JDK version as Sun's java version "1.4.2_02" before showing the test results. As for the correctness of the mauve testcase I made, I am confident of it. And my opinions on the discussed issue are: 1. Should the mauve test conform to Sun's implementation even if it seems incorrect? No. 2. Should GNU Classpath (or other implementations) simulate Sun's implementation even if it seems incorrect? Yes, if it is necesary. These derives from Dalibor's saying in an article of Kaffe mailing list: Date:Tue, 01 Jul 2003 03:09:43 MST Subject: Re: [kaffe] Bug report (java.io.StreamTokenizer) Respect latest JDK API specs where you can, and do as Sun does where you must ;) And in the case of 12 AM/PM issue, I do not think we should simulate Sun's bug. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: GregorianCalendar fixes
On Friday 28 November 2003 15:43, Dalibor Topic wrote: > In the long run, the JDK is as irrelevant as an industry standard as SCO > Unix is now. Ten years ago, there were many (closed source) > implementations of Unix-ish OSes. GNU/Linux is gradually replacing them. > > I boldly predict that the same will happen with Java. True WORA for Java > will arrive, but it will arrive through free software efforts like mauve > & GNU Classpath [2] that will provide the next reference platform. me2 -- Chris Gray /k/ Embedded Java Solutions Embedded & Mobile Java, OSGi http://www.kiffer.be/k/ [EMAIL PROTECTED] +32 477 599 703 ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: GregorianCalendar fixes
Hi Stephen, Stephen Crawley wrote: [EMAIL PROTECTED] said: A mauve test attached. Since I have got a write access to the mauve CVS registry, I will add it to the registry. The test results shows that Sun's implementation also seems to have something wrong. If Sun's implementation (you don't say which JDK version!) is failing a test, then that casts serious doubt on the correctness of the mauve testcase itself! Sure. On the other hand, it also casts doubts on the quality of Sun's implementation. The JDK is quite buggy, see the JDK Bug Parade for a reference. The implementations are often less buggy that what we have in GNU Classpath or kaffe at the moment, but they are far from perfect, in my experience. I don't usually have much trouble crashing Sun's 1.4.2 VM with my java code. ;) After looking at the test case, I'd say that it excercises a bit of a very badly specified area of the JDK. java.util.Calendar has a very, very ugly API. You can set the fields separately, but setting them can trigger recalculations & clearing of other, related fields. Unfortunately, how the changes propagate is not very well documented, unless you shelve out the cash for the Java Class Libraries Vol. 1, 2nd Edition & and the Vol. 1, 2nd Edition Supplement books. Even then, it's not very clear that if setting HOUR first (which triggers an update of AM_PM) and then set AM_PM (which triggers an update of HOUR) has the same effect as setting AM_PM first and then setting HOUR. I've tried Ito's test case with the setting of AM_PM and HOUR in reverse. The results for the JDK 1.4.2 are the same, it still breaks on the same four test cases as before. Clearing the calender to avoid side effects in field computation because of current time's fields being set doesn't help, either. Bascially, there seems to be no way to tell Sun's JDK that you want to have 12:[00-59] [AM|PM] by using the set(field, value) API. [1] Which looks like a bug in Sun's implemenation to me, and this test exposes it. The over-arching principle for Mauve testcases is that the behavior of Sun's Java implementations is the "gold standard" for conformance testing. Even if the Sun Java behavior contradicts the javadocs, or is "just plain wrong", it is still technically "correct behavior" from the POV of conformance. That depends on the situation. If the behaviour is clearly a bug, like in the above case, I'd say report it to Sun, make sure Classpath does it better, and have a mauve test to expose the bug in the JDK. After all, the goal shouldn't be to just have the classes, it should be to have the superior implementation. Having a test suite of our own helps in showing that everyone's implementations are buggy, but at least you can fix the free ones and share the fixes ;) [Sun sometimes acknowledges JDK bugs, but then says they won't fix them. because of the risk of breaking existing customer code. In such cases, other Java implementations need to be bug-for-bug compatible in order to minimize cross-platform portability problems for developers and end-users.] Yes, but they also fix a lot of bugs between releases, judging by their release notes. If the software depends on the bug, I'd say fix the software ;) If the software depends on some badly specified part of the spec, I'd say write tests & make sure we understand that part well, so that we can make Classpath's code even better than the JDK. Which is the case here, I believe. In the long run, the JDK is as irrelevant as an industry standard as SCO Unix is now. Ten years ago, there were many (closed source) implementations of Unix-ish OSes. GNU/Linux is gradually replacing them. I boldly predict that the same will happen with Java. True WORA for Java will arrive, but it will arrive through free software efforts like mauve & GNU Classpath [2] that will provide the next reference platform. cheers, dalibor topic [1] Unless you can somehow guess that setting AM_PM seems to wrap the clock time around in a rather weird way, so that when it's 12 and you set it to PM, you get AM, but when it's 12 and you set it to PM, you get AM. [2] And kaffe, gcj, sablevm, kissme, etc. of course ;) ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: GregorianCalendar fixes
Hi, On Fri, 2003-11-28 at 04:39, Stephen Crawley wrote: > Mark Wielaard <[EMAIL PROTECTED]> wrote: > > On Fri, 2003-11-28 at 02:03, Stephen Crawley wrote: > > > The over-arching principle for Mauve testcases is that the behavior of > > > Sun's Java implementations is the "gold standard" for conformance > > > testing. > > > > I don't agree. We should not create Mauve tests to validate some > > proprietary library implementation. > > I don't understand what you are saying here. Sorry, was way past my bedtime. Maybe I should have taken more time explain. I was mainly disturbed by the suggestion that some proprietary implementation should be pointed out as the "gold standard" and that if that same implementation decides not to fix bugs then it isn't a bug. There are lots of examples of bugs in some widely used implementations. Mauve points those out. For example floating point string representation, or solving the solutions for some quadratic equation and very possible representations of date and time. I haven't checked Ito his test yet, but I hope you agree that even though some implementation might claim say that a certain month has 35 days then it is obviously a bug and not according to spec. What you seem to want is a list of bugs in certain implementations according to Mauve and an explanation why that bug is or isn't solved in that implementation. We don't provide that. Even though it might be useful for some of our users. > We are not building Mauve > tests in order to validate Sun's implementation. Rather, we are > building it to check that other implementations (including Classpath) > conform to the accepted specification for Java. The ultimate > specification for Java is (according to Sun) the behaviour of Sun's > reference implementations. > > Are you suggesting that there is a more appropriate or more definitive > specification of Java? If so, what is it, and why is it more > appropriate or definitive? No. Since Sun says what Java is and claims trademark on products which carry that name. It is their definitive specification: "The thing that according to Sun is Java". So by definition Mauve isn't The Java Testsuite. But there are publicly published documents and books about the libraries and what Mauve can claim is that it is a testsuite that follows these publicly published specification as closely as possible without favoring any actual implementation. Mauve is a reference test suite that everybody can use and study and might even adapt (to better reflect their understanding of the spec) and publish its own version, which validates differences between core library implementations. In that sense Mauve is its own specification. And for our users it is certainly very useful to use Mauve to compare implementations against the currently dominant proprietary implementation to see if another implementation can be used to easily migrate away from the that implementation. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: GregorianCalendar fixes
Mark Wielaard <[EMAIL PROTECTED]> wrote: > On Fri, 2003-11-28 at 02:03, Stephen Crawley wrote: > > The over-arching principle for Mauve testcases is that the behavior of > > Sun's Java implementations is the "gold standard" for conformance > > testing. > > I don't agree. We should not create Mauve tests to validate some > proprietary library implementation. > > Mark I don't understand what you are saying here. We are not building Mauve tests in order to validate Sun's implementation. Rather, we are building it to check that other implementations (including Classpath) conform to the accepted specification for Java. The ultimate specification for Java is (according to Sun) the behaviour of Sun's reference implementations. Are you suggesting that there is a more appropriate or more definitive specification of Java? If so, what is it, and why is it more appropriate or definitive? -- Steve ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: GregorianCalendar fixes
Hi, On Fri, 2003-11-28 at 02:03, Stephen Crawley wrote: > The over-arching principle for Mauve testcases is that the behavior of > Sun's Java implementations is the "gold standard" for conformance > testing. I don't agree. We should not create Mauve tests to validate some proprietary library implementation. Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: GregorianCalendar fixes
[EMAIL PROTECTED] said: > A mauve test attached. Since I have got a write access to the mauve > CVS registry, I will add it to the registry. The test results shows > that Sun's implementation also seems to have something wrong. If Sun's implementation (you don't say which JDK version!) is failing a test, then that casts serious doubt on the correctness of the mauve testcase itself! The over-arching principle for Mauve testcases is that the behavior of Sun's Java implementations is the "gold standard" for conformance testing. Even if the Sun Java behavior contradicts the javadocs, or is "just plain wrong", it is still technically "correct behavior" from the POV of conformance. [Sun sometimes acknowledges JDK bugs, but then says they won't fix them. because of the risk of breaking existing customer code. In such cases, other Java implementations need to be bug-for-bug compatible in order to minimize cross-platform portability problems for developers and end-users.] -- Steve ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: GregorianCalendar fixes
Hi, > ":" == Mark Wielaard <[EMAIL PROTECTED]> writes: :> Looked some more at the code and I see now that the the first change was :> inside a if (time >= gregorianCutover) so it now makes more sense to me. :> And the second change seems correct given the above remark. :> I'll commit it in Classpath. There is another difference between GNU Classpath's java/util/GregorianCalendar.java and that of kaffe. Kaffe's was imported from GNU Classpath and modified in the kaffe world, as described by the following ChangeLog entry. 2003-08-16 Guilhem Lavaux <[EMAIL PROTECTED]> * java/util/GregorianCalendar.java (computeTime): 12:00 midnight is AM and 12:00 noon is PM. Here is the patch that can be applied to Revision 1.21: --- java/util/GregorianCalendar.java.orig Thu Nov 27 15:35:08 2003 +++ java/util/GregorianCalendar.javaThu Nov 27 15:48:25 2003 @@ -402,7 +402,11 @@ { hour = fields[HOUR]; if (isSet[AM_PM] && fields[AM_PM] == PM) - hour += 12; + if (hour != 12) /* not Noon */ +hour += 12; + /* Fix the problem of the status of 12:00 AM (midnight). */ + if (isSet[AM_PM] && fields[AM_PM] == AM && hour == 12) + hour = 0; } int minute = isSet[MINUTE] ? fields[MINUTE] : 0; A mauve test attached. Since I have got a write access to the mauve CVS registry, I will add it to the registry. The test results shows that Sun's implementation also seems to have something wrong. Here is the output of the tests. Kaffe + kaffe's GregorianCalendar gnu.testlet.java.util.Calendar.ampm PASS: gnu.testlet.java.util.Calendar.ampm (number 1) PASS: gnu.testlet.java.util.Calendar.ampm (number 2) PASS: gnu.testlet.java.util.Calendar.ampm (number 3) PASS: gnu.testlet.java.util.Calendar.ampm (number 4) PASS: gnu.testlet.java.util.Calendar.ampm (number 5) PASS: gnu.testlet.java.util.Calendar.ampm (number 6) PASS: gnu.testlet.java.util.Calendar.ampm (number 7) PASS: gnu.testlet.java.util.Calendar.ampm (number 8) PASS: gnu.testlet.java.util.Calendar.ampm (number 9) PASS: gnu.testlet.java.util.Calendar.ampm (number 10) PASS: gnu.testlet.java.util.Calendar.ampm (number 11) PASS: gnu.testlet.java.util.Calendar.ampm (number 12) PASS: gnu.testlet.java.util.Calendar.ampm (number 13) PASS: gnu.testlet.java.util.Calendar.ampm (number 14) PASS: gnu.testlet.java.util.Calendar.ampm (number 15) PASS: gnu.testlet.java.util.Calendar.ampm (number 16) 0 of 16 tests failed Kaffe + GNU Classpath's GregorianCalendar gnu.testlet.java.util.Calendar.ampm FAIL: gnu.testlet.java.util.Calendar.ampm (number 1) got 12:00 PM but expected 12:00 AM FAIL: gnu.testlet.java.util.Calendar.ampm (number 2) got 12:00 PM but expected 12:00 AM FAIL: gnu.testlet.java.util.Calendar.ampm (number 3) got 12:10 PM but expected 12:10 AM FAIL: gnu.testlet.java.util.Calendar.ampm (number 4) got 12:10 PM but expected 12:10 AM PASS: gnu.testlet.java.util.Calendar.ampm (number 5) PASS: gnu.testlet.java.util.Calendar.ampm (number 6) PASS: gnu.testlet.java.util.Calendar.ampm (number 7) PASS: gnu.testlet.java.util.Calendar.ampm (number 8) FAIL: gnu.testlet.java.util.Calendar.ampm (number 9) got 12:00 AM but expected 12:00 PM FAIL: gnu.testlet.java.util.Calendar.ampm (number 10) got 12:00 AM but expected 12:00 PM FAIL: gnu.testlet.java.util.Calendar.ampm (number 11) got 12:10 AM but expected 12:10 PM FAIL: gnu.testlet.java.util.Calendar.ampm (number 12) got 12:10 AM but expected 12:10 PM PASS: gnu.testlet.java.util.Calendar.ampm (number 13) PASS: gnu.testlet.java.util.Calendar.ampm (number 14) PASS: gnu.testlet.java.util.Calendar.ampm (number 15) PASS: gnu.testlet.java.util.Calendar.ampm (number 16) 8 of 16 tests failed Sun's java version "1.4.2_02" gnu.testlet.java.util.Calendar.ampm FAIL: gnu.testlet.java.util.Calendar.ampm (number 1) got 12:00 PM but expected 12:00 AM PASS: gnu.testlet.java.util.Calendar.ampm (number 2) FAIL: gnu.testlet.java.util.Calendar.ampm (number 3) got 12:10 PM but expected 12:10 AM PASS: gnu.testlet.java.util.Calendar.ampm (number 4) PASS: gnu.testlet.java.util.Calendar.ampm (number 5) PASS: gnu.testlet.java.util.Calendar.ampm (number 6) PASS: gnu.testlet.java.util.Calendar.ampm (number 7) PASS: gnu.testlet.java.util.Calendar.ampm (number 8) FAIL: gnu.testlet.java.util.Calendar.ampm (number 9) got 12:00 AM but expected 12:00 PM PASS: gnu.testlet.java.util.Calendar.ampm (number 10) FAIL: gnu.testlet.java.util.Calendar.ampm (number 11) got 12:10 AM but expected 12:10 PM PASS: gnu.testlet.java.util.Calendar.ampm (number 12) PASS: gnu.testlet.java.util.Calendar.ampm (number 13) PASS: gnu.testlet.java.util.Calendar.ampm (number 14) PASS: gnu.testlet.java.util.Calendar.ampm (number 15) PASS: gnu.testlet.java.util.Calendar.ampm (number 16) 4 of 16 tests failed The Mauve test program: // Tags: JDK1.1 // Copyright (c) 2003 Ito Kazumitsu // This file is part of Mauve. package gnu.testlet.java.util.Calendar; import gnu.testlet.Testlet; imp
Re: GregorianCalendar fixes
Hi, On Mon, 2003-11-24 at 23:57, Ito Kazumitsu wrote: > > 2003-11-25 Ito Kazumitsu <[EMAIL PROTECTED]> > > * java/util/GregorianCalendar.java (getLinearTime): Avoid counting > the leap day of the leap year twice. > (computeFields): First week of month is 1 not 0. Thanks (I made it real sentences - starting with a capital). Looked some more at the code and I see now that the the first change was inside a if (time >= gregorianCutover) so it now makes more sense to me. And the second change seems correct given the above remark. I'll commit it in Classpath. Thanks for your work (and patience before it was accepted), Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: GregorianCalendar fixes
> ":" == Mark Wielaard <[EMAIL PROTECTED]> writes: :> and to have a ChangeLog entry for this patch (Ito?). How about this? 2003-11-25 Ito Kazumitsu <[EMAIL PROTECTED]> * java/util/GregorianCalendar.java (getLinearTime): avoid counting the leap day of the leap year twice. (computeFields): corrected so that the first week of month is not 0 but 1. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: GregorianCalendar fixes
Mark Wielaard wrote: Hi, Since I am not a GregorianCalendar expert I was hoping that someone could review the following patch which I have in my tree from Ito Kazumitsu. He and I wrote a couple of mauve test cases which are fixed by this and I see no new failures. But people didn't seem to be completely comfortable with it back in Augustus/September. It would be nice if we could create even more test cases to make sure that nothing else breaks and to have a ChangeLog entry for this patch (Ito?). Don't really have have time to learn about Calendars so I am just re-posting this patch in the hope that someone can review it. I am not expert enough for a review ;) But here the results: http://gcc.gnu.org/ml/gcc-testresults/2003-11/msg00990.html CHeers, Andreas ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
GregorianCalendar fixes
Hi, Since I am not a GregorianCalendar expert I was hoping that someone could review the following patch which I have in my tree from Ito Kazumitsu. He and I wrote a couple of mauve test cases which are fixed by this and I see no new failures. But people didn't seem to be completely comfortable with it back in Augustus/September. It would be nice if we could create even more test cases to make sure that nothing else breaks and to have a ChangeLog entry for this patch (Ito?). Don't really have have time to learn about Calendars so I am just re-posting this patch in the hope that someone can review it. Thanks, Mark Index: java/util/GregorianCalendar.java === RCS file: /cvsroot/classpath/classpath/java/util/GregorianCalendar.java,v retrieving revision 1.20 diff -u -r1.20 GregorianCalendar.java --- java/util/GregorianCalendar.java 12 Aug 2003 13:41:27 - 1.20 +++ java/util/GregorianCalendar.java 21 Nov 2003 16:11:56 - @@ -1,5 +1,5 @@ /* java.util.GregorianCalendar - Copyright (C) 1998, 1999, 2001, 2002 Free Software Foundation, Inc. + Copyright (C) 1998, 1999, 2001, 2002, 2003 Free Software Foundation, Inc. This file is part of GNU Classpath. @@ -264,8 +264,10 @@ // // The additional leap year factor accounts for the fact that // a leap day is not seen on Jan 1 of the leap year. + // And on and after the leap day, the leap day has already been + // included in dayOfYear. int gregOffset = (year / 400) - (year / 100) + 2; - if (isLeapYear (year, true) && dayOfYear < 31 + 29) + if (isLeapYear (year, true)) --gregOffset; time += gregOffset * (24 * 60 * 60 * 1000L); } @@ -604,12 +606,12 @@ calculateDay(++day, gregorian); } -fields[DAY_OF_WEEK_IN_MONTH] = (fields[DAY_OF_MONTH] + 6) / 7; +fields[DAY_OF_WEEK_IN_MONTH] = (fields[DAY_OF_MONTH] + 12) / 7; // which day of the week are we (0..6), relative to getFirstDayOfWeek int relativeWeekday = (7 + fields[DAY_OF_WEEK] - getFirstDayOfWeek()) % 7; -fields[WEEK_OF_MONTH] = (fields[DAY_OF_MONTH] - relativeWeekday + 6) / 7; +fields[WEEK_OF_MONTH] = (fields[DAY_OF_MONTH] - relativeWeekday + 12) / 7; int weekOfYear = (fields[DAY_OF_YEAR] - relativeWeekday + 6) / 7; signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath