Phew! I already thought I was crazy :) In that case here are two more tidbits: - I tried to log âDateAndTime nowâ in a different test simultaneously. The timestamp produced there was different, suggesting that the clock does move from time to time. - FileSystemTests>>testEntryAt exhibits that problem. But the tests run on the main Pharo machines are fine (thatâs why I thought it might be the system clock). - the same test only fails in the Pharo3 image, not in Pharo2, but both use the stable PharoVM for building. Hope that helps. On 04.03.2014, at 22:10, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hey Max,
Great catch, I saw some weird stuff too, and we had this conversation :
may be just = and time does not pass fast enough/
On 03 Mar 2014, at 22:22, no-reply@ci.inria.fr wrote:
https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation-A-L/label...
1 regressions found. KernelTests.Chronology.DateAndTimeTest.testMonotonicity
How the hell can this fail ? The clock moving backwards ??
testMonotonicity
| t1 t2 t3 t4 | t1 := DateAndTime now. t2 := DateAndTime now. (Delay forMilliseconds: 1000) wait. t3 := DateAndTime now. t4 := DateAndTime now.
self assert: (t1 <= t2); assert: (t2 < t3); assert: (t3 <= t4).
So you proofed Stef's assumption of time standing still ;-)
But there were earlier problems as well.
Thx !
On 04 Mar 2014, at 21:43, Max Leske <maxleske@gmail.com> wrote:
There seems to be a problem on pharo-contribution-linux64-4.ci.inria.fr AFAICT. I can reproduce the following to phenomena:
1. '(Delay forSeconds: 10) waitâ does not wait. 2. âDateAndTime nowâ does not change for long intervals.
For instance, the following code:
(FileSystem disk workingDirectory / 'foo.log') writeStreamDo: [ :stream | stream nextPutAll: DateAndTime now asString;crlf. stream nextPutAll: ([(Delay forSeconds: 10) wait] timeToRun / 1000) asString; crlf. stream nextPutAll: DateAndTime now asString ].
produces this output:
2014-03-04T21:32:21.396669+01:00 0:00:00:00 2014-03-04T21:32:21.396669+01:00
Too me (and my untrained eye) this looks like a system clock problem. Could somebode take a look at the server in question?
Cheers, Max