<div><br></div><div >HI all,<br></div><div ><br></div><div >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.  <br></div><div ><br></div><div >If I remember I will run a squeak image over the US timezone change this coming Sunday and check just to be sure.<br></div><div ><br></div><div >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.<br></div><div ><br></div><div >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.<br></div><div ><br></div><div >In terms of leap seconds....<br></div><div ><br></div><div >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.<br></div><div ><br></div><div><a href="https://access.redhat.com/articles/15145">https://access.redhat.com/articles/15145</a><br></div><div><br></div><div>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.</div><div ><br></div><div >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.<br></div><div ><br></div><div >Calculating into the future would be risky as well since new leap seconds only have about a 6 month announcement period.<br></div><div ><br></div><div >Finally, while it has not happened leap seconds can also be negative.</div><div ><br></div><div >cheers<br></div><div ><br></div><div >bruce<br></div><div ><br></div><div ><br></div><div ><br></div><div class="ik_mail_quote"><div>On 2021-11-04T03:41:11.000+01:00, David T. Lewis <lewis@mail.msen.com> wrote:</div><blockquote class="ws-ng-quote"><pre style="white-space: normal;">Hi Nicola,<br><br>Actually this is an issue that must be handled in the image.<br>If you look at DateAndTime now in Squeak (any recent image)<br>you can see that it uses primitiveUtcWithOffset to obtain the<br>current time (UTC) and timezone offset, so Squeak is able to<br>follow the daylight savings time transition correctly. Cuis is<br>using a different implementation of DateAndTime based on an<br>older Squeak version, and that is the source of the issue you<br>are seeing.<br><br>Dave<br><br><br>On Wed, Nov 03, 2021 at 09:05:11AM -0700, Dr. Nicola Mingotti wrote:<br><blockquote class="ws-ng-quote">   <br> Hi guys,<br> <br> 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. <br> <br> =============== Original mail to cuis mailing list descriving the problem ====================<br> I report you what i discovered this morning.<br> <br> . I have 2 services running in Cuis in 2 independent Linux/Debian servers.<br> <br> . In the weekend in Italy we changed time from CEST to CET<br> <br> . The OSes changed time correctly<br> <br> . But Cuis services are 1 hour forward !?!?<br> <br> . 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<br> <br> . I did not change my localTimeZone in Cuis, in any machine. It is acceptable for me it says UTC<br>   even if it is actually localtime.<br> <br> . Seeing 'DateAndTime now' I discovered that Cuis by default uses primLocalMicrosecondClock, so it should<br>   always use the OS local clock and think it is in the UTC timezone. But, it is not doing<br>   so on images that were started some days ago (max 20). It does so on new run images.<br> <br> I don't know well how to fix this. Maybe some time config is made when Cuis starts up?<br> It seems it is remembering the time when it was stared.<br> <br> =============================================================================<br> <br> <br> -- <br> You are receiving this because you are subscribed to this thread.<br> Reply to this email directly or view it on GitHub:<br> <a target="_blank"  class="defaultMailLink" href="https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/602">https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/602</a></pre></blockquote></div>