Computing desk
< November 4	<< Oct \| November \| Dec >>	November 6 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is a transcluded archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

November 5[edit]

What happens when the time changes?[edit]

If I was sitting at the computer this Saturday night (early November 7) what would happen to the display of the time, and how would it happen? I am in the United States and not in one of the areas that does not observe Daylight Savings Time.— Vchimpanzee • talk • contributions • 21:52, 5 November 2021 (UTC)[reply]

You should just see the display jump back. Remember that the computer's clock (ok, on all computers built within the last 30 years) keeps GMT and then adds the timezone difference for display purposes. The clock itself doesn't need to change. We, in the UK, had the change last weekend and my phone seamlessly jumped back from 0200 to 0100, which was weird - I woke to go to the loo at some time just after 0100, then an hour later it was again just after 0100! Martin of Sheffield (talk) 23:13, 5 November 2021 (UTC)[reply]

Windows as with DOS before it, is still configured to treat the system clock as local time by default, and so probably most desktop and laptop computers keep the time as local time. It's possible to change Windows to treat the system clock as UTC but outside of multi boot configurations I don't think this is very common. [1] [2]

As mentioned in the second of those links, on older versions of Windows, some versions of Vista (pre SP2) and older (i.e. ~15 years ago) this change wasn't even well supported leading to bugs. It sounds like it was added to NT for non x86 derived computers but not something they paid much attention to after these were abandoned. I think on DOS derived versions of Windows, there wasn't even an option to treat the system time as UTC, as was the case on DOS.

Even with modern multi boot configurations, I suspect a lot of people who simply install Ubuntu get it to follow Windows behaviour since it tends to be a configuration option either automatically performed during install in multi boot configs or offered unlike in Windows where AFAIK in all versions it's still something that requires editing the registry manually or some additional system tweaker.

As to how the OS copes with time zone changes, mostly it isn't that different except it also needs to automatically adjusts the RTC when the time changes. Since there's no guarantee the OS will be running at the time of the change, it keeps a record of whether it's performed the change so it knows whether it needs to adjust it, however as there isn't any standard way to store this on the RTC or BIOS/EFI, this is stored by the OS internally (on Windows in the registry I believe).

As may be obvious, this can be problematic on multi boot configurations since they aren't generally designed to cross communicate, so if they aren't running during the change, there's no way they can know if the other OS has already performed the change. Indeed during for the hour (or whatever) period when the clock is moved back, if they aren't running during the change they can't even be sure what the current time is meant to represent. Most likely they will rely on clock synchronisation over the internet to help determine whether adjustment is needed or worst case user intervention. (Possibly some versions of *nix never adjust the RTC & instead just store it internally whether it's been adjusted with the help of clock synchronisation, to reduce problems with Windows getting confused, not sure.)

Nil Einne (talk) 09:18, 6 November 2021 (UTC)[reply]

Oops, suitably admonished. I was talking about Linux, UNIX and OpenVMS systems. I'm suprised at Nil Einne's comments, I hadn't realised that Windows was still so primitive in its clock handling. Running NTP (or similar) will sort the issue out as Nil says. Back in the 80s we had similar problems with VAXen, the trick was to set the commands up on the system consoles, and then run along as quickly as possible pressing return in an attempt to keep them synchronized. Martin of Sheffield (talk) 09:28, 6 November 2021 (UTC)[reply]

I glimpsed at the date-and-time header in the top bar of the macOS screen to see if the time had already fallen back, saw 03:00, and while I was looking it changed into 02:00. It was pure coincidence that I looked precisely at that instant. I'd have expected the display to jump immediately from 02:59 to 02:00. A radio-controlled clock I have laboriously moves its long hand at an increased pace 13 turns forward. --Lambiam 13:51, 6 November 2021 (UTC)[reply]