Why does OS not change time twice on daylight savings time rollback

Latest response

My system has correct timezone file and am sure it will change time from 2AM to 1AM on Nov 3.
But why does system not change twice when the clock reaches 2AM after first change? Is there any flag or hardware clock is compared?

I tested DST rollback multiple times, OS changes time to 1AM whenever. So, when the time changes on Nov 3, how can OS stop changing time?

zdump -v | grep 2019 shows zone info changes from CDT to CST, and gmfoff is different.

I am cursious how OS recognizes manual change and real change..

Responses

The time change is not at 02:00 local time (which appears to happen twice on that day), it happens at 06:00 UTC (and UTC time doesn't change, at least not for Daylight Saving time). So the second time your system displays "2:00 AM", it is actually 07:00 UTC, which does not have a scheduled local time change in your time zone.

James, Does it mean that OS will take only change made on UTC 6 as a real DST change and when it moves forward second time to 2AM, it won't roll back again to 1AM localtime?

Hi Sungpill,

The second time it is not DST anymore, your timezone will have changed to "Standard time" and like James Nauer explains, it is UTC time that is used to trigger the timezone change.

You can do an experiment in the weekend of October 25th and October 26th. Set the TZ environment variable to CET (Central European Time)

On Saturday 25th the date command will show a time with CEST as the timezone.

Like right now:

date Thu Oct 10 22:17:28 CEST 2019

On Sunday 26th after 2:00 AM CEST time stamps will show:

Sun OCt 26 xx:yy:zz CET 2019

So the display time will show a slightly different timezone, where as UTC has just advanced without jumping back and forward.

Only mother Earth, her sister the Moon and the big mum the Sun are having a slight effects on UTC, we call them leap seconds.

Regards,

Jan Gerrit Kootstra

In Unix-style systems (including Linux) the system clock internally runs in UTC, and all system timestamps are likewise stored internally in UTC. The DST changes happen at specific points in UTC time: at those points, the UTC offset value (named "gmtoff" for historical reasons) used in converting the timestamps between the internal UTC representation and local time is changed. And that is the only change - the system clock is not actually touched at all!

On Linux, the hardware clock that keeps the system time when the computer is shut down can be set in either local time or in UTC time. If you have it in UTC time, nothing needs to be done to it when DST begins or ends. As long as your timezone information is up to date, the UTC value of any timestamp will always be converted to the local time for display according to the current DST rules of your timezone.

If you have a dual-boot system, or for some other reason have the system clock running in local time, the system looks at the stored UTC timestamp of the last change of the root filesystem when booting up. If that timestamp was from before a DST transition, and the clock says the current time is now after the scheduled DST transition, then the hardware clock is shifted accordingly, and the on-disk UTC timestamp is updated to an "after the transition" value.

However, this workaround is not perfect: if you boot the system twice within the one-hour window of the DST-to-standard transition and all the necessary circumstances line up, it is possible for the system to make a double transition. But the system will try very hard to avoid it, and if your system is set to use NTP time synchronization, the double transition will be automatically fixed as soon as the network connection comes up and the NTP server is accessible.

On dual-boot systems, you should pick one operating system to be the one handling the DST transitions, and only allow that OS to adjust the hardware clock.