[Vm-dev] [OpenSmalltalk/opensmalltalk-vm] Possible nasty bug in time management (Issue #602)

[Bruce O'Neel]

HI all,

Yes it seems that Squeak should deal with the time zones changes to
and from summer time correctly in an image that is running over a time
change.  It would be important to keep in mind that time would not be
monotonically increasing and that might cause some indigestion though.
 I would personally recommend that for server images you use UTC
rather than local time just so that, minus leap seconds, time will
only increase.  

If I remember I will run a squeak image over the US timezone change
this coming Sunday and check just to be sure.

If you want your laptop to properly get your new timezone right if you
cross time zones and you have a long running image you do need to call
Time primitiveUpdateTimeZone though.  It seems that the timezone is
only checked on startup otherwise.

You also would have to do this if your timezone changes on its own,
say, your country or region changes going to and from summer time on a
different day, someone redraws a border and your sever is magically in
a new timezone, etc.

In terms of leap seconds....

Linux and other unix systems basically ignore leap seconds and depend
on some time sync service  to deal with that and move the clock
around, either in +-1 second jumps or by stretching or shrinking the
length of a second.

https://access.redhat.com/articles/15145

So if you do not run NTP, Chrony, or something like that your Linux
system will just ignore leap seconds.  MacOS works in a similar way.
 I don't know about Windows.

We do not seem to keep a list of leap seconds in the image so that
means that time calculations over a leap second will be wrong by one
or more seconds.  You are safe if both dates are before 1972 or after
Jan 1 2017 but in-between across either midnight UTC on 30 June or 31
December you run the risk of being off by one second.  Since there
have been 27 leap seconds your error will be no worse than that.

Calculating into the future would be risky as well since new leap
seconds only have about a 6 month announcement period.

Finally, while it has not happened leap seconds can also be negative.

cheers

bruce

On 2021-11-04T03:41:11.000+01:00, David T. Lewis <lewis at mail.msen.com>
wrote:

Hi Nicola,

Actually this is an issue that must be handled in the image.
If you look at DateAndTime now in Squeak (any recent image)
you can see that it uses primitiveUtcWithOffset to obtain the
current time (UTC) and timezone offset, so Squeak is able to
follow the daylight savings time transition correctly. Cuis is
using a different implementation of DateAndTime based on an
older Squeak version, and that is the source of the issue you
are seeing.

Dave

On Wed, Nov 03, 2021 at 09:05:11AM -0700, Dr. Nicola Mingotti wrote:
   
 Hi guys,
 
 I found this bug running Cuis on my servers. I reported to the Cuis mailing list and after reply by Gerald Klix I guess this is the most appropriate place to tell it. I copy the same message i wrote on morning of 03-Nov-2021 in the hope you will be able to fix it. Unfortunately i can't help you, VM is still too much an unknown territory for me. 
 
 =============== Original mail to cuis mailing list descriving the problem ====================
 I report you what i discovered this morning.
 
 . I have 2 services running in Cuis in 2 independent Linux/Debian servers.
 
 . In the weekend in Italy we changed time from CEST to CET
 
 . The OSes changed time correctly
 
 . But Cuis services are 1 hour forward !?!?
 
 . If i run a fresh new Cuis now in my laptop (Linux/debian vm), I see it has the correct time, corresponding to the OS time
 
 . I did not change my localTimeZone in Cuis, in any machine. It is acceptable for me it says UTC
   even if it is actually localtime.
 
 . Seeing 'DateAndTime now' I discovered that Cuis by default uses primLocalMicrosecondClock, so it should
   always use the OS local clock and think it is in the UTC timezone. But, it is not doing
   so on images that were started some days ago (max 20). It does so on new run images.
 
 I don't know well how to fix this. Maybe some time config is made when Cuis starts up?
 It seems it is remembering the time when it was stared.
 
 =============================================================================
 
 
 -- 
 You are receiving this because you are subscribed to this thread.
 Reply to this email directly or view it on GitHub:
 https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/602

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20211104/8756c8bb/attachment-0001.html>