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.
=============================================================================
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
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@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
Thanks for the feedback, Dave.
That area was outdated in Cuis essentially for compatibility with older VMs. Time has come, though. I just pushed updates to the Cuis repo that use (and require) the newer primitives.
Cheers,
On 11/3/2021 11:41 PM, David T. Lewis 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
Hi guys, thank you for your comments, after them i made the following experiment that confirms Dave view. * In the test below I try to run correspondendts commands in my laptop and a remove server as near in time as i can. * `primLocalMicrosecondClock` primitive is **not able** to handle time change in the OS * `primtUtc*` **are capable** of managing time change in the OS * Therefore, i would say the easiest fix would be for us to move Cuis to a primtUtc* primitive ``` " --- server, long running image (max 30 days) ----- " Time primUtcMicrosecondClock . " 3813468560 557 013 " Time primUtcWithOffset sum . " 1636015592 614 478 " Time primLocalMicrosecondClock . " 3813476132 229 495 "
" --- my laptop, fresh run image -----" Time primUtcMicrosecondClock . " 3813468562 809 323 " Time primUtcWithOffset sum. " 1636015588 248 736 " Time primLocalMicrosecondClock . " 3813472528 768 737 " ```
Closed #602.
**ATTENTION**. In my previoius post there is an ugly mistake. We can not do `sum` on `Time primUtcWihOffset` because the time units are different. Anyway the idea is clear.
vm-dev@lists.squeakfoundation.org
-
Bruce O'Neel -
David T. Lewis -
Dr. Nicola Mingotti -
Juan Vuletich