Hi Marcel,

On Thu, Feb 18, 2016 at 12:07 AM, marcel.taeumel <Marcel.Taeumel at hpi.de>
wrote:

> Hi, there!
>
> The VM seems to "cache" the wall clock. This is weird.
>
> Here is the story: I just booted into Windows and my time was wrong. Seems
> to be come Surface bug. It still was at the sleep time yesterday evenening,
> 11pm.
>
> Squeak was already open, reporting the same.
>
> Then, I updated the system time by letting Windows sync with Microsofts
> time
> server.
>
> And then, the still running Squeak VM reported still the old values!!! :-/
> How can that happen?
>

By my having coded time management in the Windows VM wrong?  Look at
sqWin32Heartbeat.c.
This all needs rewriting anyway given the discussion on monotonic vs wall
time.   I'd like to have one copy of the code that computes the VM's notion
of time, perhaps written in Smalltalk, and place that above
platform-specific code that answers the monotonic and wall clocks.

But what should the VM do if it is faced with a huge jump in the time?
Let's say that for testing you set the clock on your machine to 1970, then
you started Smalltalk, and then you enabled syncing with the time server
and the clock jumped forward to 2016.  One could have the VM try to
compensate but I think the best thing is to say "don't do that" and require
teh user to restart their image.  It's reasonable for the VM to maintain a
clock that undergoes ntpd-like adjustments.  It's complicated to have the
VM try and distinguish small ntpd-like adjustments form huge adjustments in
the clock.  And keeping it simple seems like the best solution.


> <http://forum.world.st/file/n4878340/bug-time.png>
>
> Best,
> Marcel
>
>
>
> --
> View this message in context:
> http://forum.world.st/trunk-thinks-its-tomorrow-tp4877735p4878340.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>
>


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160218/2655037f/attachment.htm