hmm, the millisecond has been set when initializing with timezone. I
fixed it at r560045. suppose it works well now. Thanks for pointing
out :)
On 7/27/07, Alexander Frey <[EMAIL PROTECTED]> wrote:
Tony,
I think this modified test isn't a valid regression test for
HARMONY-4513 anymore.
This problem only occurs if the calendar date and the cutover date of
the calendar are the same, even the milliseconds.
The constructors used in the original test set default values (0 for
milliseconds) for the date fields not given to the constructors as
parameters. The constructors in the modified test set the timezone and
initialize with the current time (including milliseconds). The set
method only modifies the date fields given as parameters, values of
other fields are not changed. This means the milliseconds of the
calendar and its cutover date are almost always different and the test
passes.
I recommend to either call gc.clear() before gc.set(year,...) or to set
the milliseconds explicit to 0. Perhaps an assertEquals() should check
the milliseconds to be sure and to 'document' this.
Regards,
Alexander
Tony Wu wrote:
> On 7/25/07, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
>> 2007/7/25, Tony Wu <[EMAIL PROTECTED]>:
>> > Hi Alexey,
>> > This testcase is added by me when fix HARMONY-4513, I think it should
>> > not depend on vm. So I'm a little confused, would you please help to
>> > try following test
>> >
>> > gGregorianCalendar c = new
>> > GregorianCalendar(TimeZone.getTimeZone("GMT"));
>> > gc.set(1582, Calendar.OCTOBER, 15, 0, 0, 0);
>> > assertEquals(1582, gc.get(Calendar.YEAR));
>> > assertEquals(Calendar.OCTOBER, gc.get(Calendar.MONTH));
>> > assertEquals(15, gc.get(Calendar.DAY_OF_MONTH));
>> > assertEquals(0, gc.get(Calendar.HOUR_OF_DAY));
>> > assertEquals(0, gc.get(Calendar.MINUTE));
>> > assertEquals(0, gc.get(Calendar.SECOND));
>> > gc.set(1582, Calendar.OCTOBER, 14, 0, 0, 0);
>> > assertEquals(24, gc.get(Calendar.DAY_OF_MONTH));
>> >
>> >
>> > if it passes and the line 732 of current GregorianCalendarTest still
>> > fails, I should say it is due to different time zone and modify the
>> > testcase. Thanks.
>>
>> This one passed on DRLVM. Indeed the key difference between VMs might
>> be in detecting default TZ: on my Linux box user.timezone=BST on J9
>> and user.timezone= (is empty) on DRLVM (that look strange BTW).
>> Anyway the testcase should not depend on this.
>
> agree, fixed at r559334.
>
>>
>> >
>> > On 7/24/07, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
>> > > Seems it fails on DRLVM only.
>> > >
>> > > 2007/7/24, Alexey Varlamov <[EMAIL PROTECTED]>:
>> > > > The recently modified GregorianCalendarTest fails now, are there
>> > > > someone looking at this?
>> > > >
>> > > > junit.framework.AssertionFailedError: expected:<15> but was:<5>
>> > > > at
>>
tests.api.java.util.GregorianCalendarTest.test_getI(GregorianCalendarTest.java:732)
>>
>> > > > at
>> java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
>> > > >
>> > >
>> >
>> >
>> > --
>> > Tony Wu
>> > China Software Development Lab, IBM
>> >
>>
>
>
--
Tony Wu
China Software Development Lab, IBM
