On 8/21/06, Jörg Schaible <[EMAIL PROTECTED]> wrote:
Hi Henri,
Henri Yandell wrote on Monday, August 21, 2006 8:29 AM:
> On 14 Aug 2006 13:05:53 -0000, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
