On Tue, Jul 15, 2014 at 03:27:59AM +0200, Levente Uzonyi wrote:
> On Mon, 14 Jul 2014, Frank Shearar wrote:
> 
> >http://build.squeak.org/job/SqueakTrunkOnSpur/31/testReport/junit/KernelTests.Chronology/DateAndTimeTest/testReadFrom/
> >shows a not-very-helpful test failure report: Expected
> >'2002-05-1...etc... but was '2002-05-1...etc....
> >
> >If build.squeak.org is anything like my machine, that failure might
> >more profitably be reported as:
> >
> >Expected '2002-05-16T17:20:00+00:00' but was '2002-05-16T17:20:00+01:00'
> >
> >from this assertion:
> >
> >self assert: '2002-05-16T17:20:00+00:00' equals: ' 2002-05-16T17:20'
> >asDateAndTime printString.
> >
> >Is this expected (because of changes in datetime primitives)?
> 
> It's unrelated to the VM. DateAndTime >> #readFrom: (since 7/5/2012) will 
> create an object in the local timezone if no timezone is specified. The 
> test and some related methods' comments expect it to be in UTC.
> The test is rather new, and I think it has always been failing.

Levente,

You are right. It was a bad test, and I caused the problem.

Fixed in KernelTests-dtl.273:

   Remove invalid assertions in DateAndTimeTest>>testReadFrom. These had been
   added to the test in KernelTests-dtl.265 in attempt to restore some missing
   test assertions from an earlier version of the method.
   
   The test assertions pass if and only if time zone has zero offset, so they
   appear to pass in an image with default UTC time zone. However, they
   contradict the documented behavior for parsing DateAndTime from a string
   with time zone offset unspecified.
   
   See DateAndTimeTest>>testFromString for coverage of the expected behavior.

Dave