harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tony Wu" <wuyue...@gmail.com>
Subject Re: [classlib][luni] GregorianCalendarTest fails now
Date Fri, 27 Jul 2007 00:58:55 GMT
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 <alexander.frey@gmx.de> 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 <alexey.v.varlamov@gmail.com> wrote:
> >> 2007/7/25, Tony Wu <wuyuehao@gmail.com>:
> >> > 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 <alexey.v.varlamov@gmail.com> wrote:
> >> > > Seems it fails on DRLVM only.
> >> > >
> >> > > 2007/7/24, Alexey Varlamov <alexey.v.varlamov@gmail.com>:
> >> > > > 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

Mime
View raw message