commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell" <flame...@gmail.com>
Subject Re: [lang] nightly build failed.
Date Tue, 22 Aug 2006 05:46:53 GMT
On 8/21/06, Jörg Schaible <Joerg.Schaible@elsag-solutions.com> wrote:
> Hi Henri,
>
> Henri Yandell wrote on Monday, August 21, 2006 8:29 AM:
>
> > On 14 Aug 2006 13:05:53 -0000, psteitz@apache.org
> > <psteitz@apache.org> wrote:
> >> Failed build logs:
> >> http://people.apache.org/~psteitz/commons-nightlies/20060814/io.log
> >>
> > http://people.apache.org/~psteitz/commons-nightlies/20060814/lang.log
> >
> > Interesting error.
> >
> > Testcase:
> > testBugzilla38401(org.apache.commons.lang.time.DurationFormatU
> > tilsTest):    FAILED expected:<...0> but was:<...1>
> > junit.framework.ComparisonFailure: expected:<...0> but was:<...1>  
  at
> > org.apache.commons.lang.time.DurationFormatUtilsTest.testBugzi
> > lla38401(DurationFormatUtilsTest.java:408)
> >       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)  at
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess
> >       orImpl.java:39) at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth
> > odAccessorImpl.java:25)
> >
> > It's not the same failure as the code had before that bug was fixed;
> > and we've only seen it the once so far over the period of nightly
> > builds. Always a pain that JUnit doesn't output the expected and was
> > text fully (when it's a small amount of text anyway).
> >
> > The expected text is:  "0000/00/30 16:00:00 000". That being the
> > difference between the following lines:
> >
> >         cal1.set(2006, 0, 26, 18, 47, 34);
> >         cal2.set(2006, 1, 26, 10, 47, 34);
> >
> > I've no idea as to where a '1' might creep in for one of the '0's.
>
> Have a second look at the JUnit ouput and you'll see, that it is the last digit we're
talking about. And the case is easy, the test code does not set the millis and it assumes,
that the call to set is within the same ms. A call to Calendar.getInstance() will initialize
the calendar with the current time. Since the call is done twice, the system time might have
been changed. With the OS shifting time, it is much more likely to happen.
>
> To fix the test, just set the millis to 0 (i.e. call setImeInMillis(0) before setting
the other values).


Thanks Jörg, that makes sense.

I've used calendar.set(Calendar.MILLISECOND, 0) instead of the
setTimeInMillis(0), but it should have the same effect I hope.
Increasingly lacking trust when using the time classes :)

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message