If you have multiple versions of Windows installed, why do they all try to adjust the clock?

Commenter Martin notes that if you have multiple copies of Windows installed on your machine, then each one will try to adjust the clock when you enter or exit daylight saving time. "I cannot believe that this feature is a bug. Please could you comment this?"

This falls into a category of issue that I like to call "So what did you expect?" (This was the catch phrase of the old Call-A.P.P.L.E. magazine.)

If you have multiple operating systems installed on your machine, each one thinks that it has control of your computer. It's not like there's some standard cross-operating system mechanism for negotiating control of hardware resources. If you install CP/M and MINIX on your machine, each one is unaware of the presence of the other. CP/M doesn't know how to mount MINIX file systems and update a configuration file to say "Hey, I updated the time, you don't need to."

And not that you would expect it to, either.

It's like signing up for two housekeeping services and telling both of them to water the plants every Monday. And lo and behold, every Monday, the plants get double-watered. There's no standard protocol for multiple housekeeping services to coordinate their activities; each housekeeping service assumes it's responsible for cleaning your house.

Bonus reading: Why does Windows keep your BIOS clock on local time?

Comments (48)
  1. Adam Rosenfield says:

    Unlike CP/M, MINIX, and housekeepers, Microsoft certainly could create such a protocol to be used only by Windows (and optionally by other OSes attempting to be compatible), but given the whole -100 points thing, this isn't likely to ever get enough traction to implement.

  2. Raphael says:

    "So what did you expect?"

    Well, keeping the time in some kind of timezone-independent way, much like UTC. Or maybe UTC. Yes, I've read the bonus reading. But I don't think the reasons stated are valid any more. Because, seriously, who actually sets their system time via BIOS instead of, say, NTP? And if you dual-boot with an OS that is no longer supported, it's their own fault. Basically, when the Vista (or later) installer did not detect any legacy OS (and by that I mean 2000/ME or newer) it should have set the Windows to use UTC.

  3. Timothy Fries says:

    "And if you dual-boot with an OS that is no longer supported, it's their own fault."

    So your solution is to take something that more or less works now and break it just for the sake of ensuring that a clock a user should never directly see is "right", for one definition of "right"?

  4. Roastbeef says:


    Since UEFI supports the concept of persistent environment variables, any chance you guys could store your "hey, I updated for DST" flag there so that at least multiple versions of windows can coexist?  And hey, once you guys put something there I'm sure the Linux folks could be persuaded to use it too.

    [Not sure who "you guys" is, but that idea gets a +1 from me. You have to deal with the "it works on some machines but not others" confusion, though. -Raymond]
  5. dave says:

    The reason for BIOS = local time is 'compatibility'.   Nowadays, back-compatibility with DOS isn't particularly important. So let's go for compatibility with systems that are not Windows, and get the benefit of 'no double daylight-saving adjustments' as well.

    I'm inclined to discount the confuse-the-user argument, on the grounds that the user who can't grasp 'BIOS = UTC' is likely already confused by merely looking at BIOS screens.  Good lord, the BIOS expects them to comprehend arcana such as 'ATA vs. AHCI'.

  6. Joshua says:

    I must second Roastbeef. Whoever came up with this idea didn't do it right.

    [So we all agree to blame CP/M? -Raymond]
  7. John says:

    @dave:  The BIOS expects nothing; it only exposes functionality.  The average user has no clue about 'ATA vs. AHCI', but they certainly are capable of adjusting the clock.  These days that type of thing is probably best left deferred to the operating system; the average user has no need to mess with the BIOS at all.

  8. Roger says:

    Note that it wouldn't be safe to go ahead and mount other file systems.  Their host operating system could have hibernated so making changes would diverge from the state in the hibernation image which leads to corruption on resume.  The only safe thing is neutral territory such as UEFI variables as mentioned by another poster.

  9. Jean says:

    Chain of events:

    • Raymond publishes the article, along with bonus reading
    • I go and read the bonus reading, even though I already read it once

    • I find a link in the comments that points to a link to http://www.cl.cam.ac.uk/…/ut-rtc.html

    • That link explains (but in a 2008 update) that setting a registry key named "RealTimeIsUniversal" in "HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTimeZoneInformation" to a value of "1" allows users of Windows Vista SP2 and Windows 7, to specify that the RTC should be set according to UTC.

    So I guess that fixes both the problems in bonus reading, and potentially in that post. I will set that up as soon as I am back home.

    So in the end, without Raymond's today's post, I may not have even heard of that registry key. Thank you Raymond!

  10. Once again, this is why I set my time zone in Windows and other operating systems to UTC.  Avoids this whole mess!

  11. +1 for storing the BIOS clock in UTC; how does storing the clock in local time work if different users have different time zones?

  12. dbt says:

    the UEFI variable seems like the only workable approach.  Requiring BIOS UTC time is a non-starter and BIOSen should not deal with time zone offsets at all, they change too frequently.  Hell, it's hard enough to keep operating systems patched to deal with the constant stream of DST timing changes.

    BTW, according to Ezra Klein of the Washington Post, DST no longer works to conserve energy anyway.  And it increases the number of traffic fatalities.  http://wapo.st/zx1YoN

  13. Mordachai says:

    +1 for storing BIOS in UTC – or even better, storing it in UEFI and having the old BIOS interrupts do internal backwards-compatibility translation to local time.

    Storing local time in the BIOS, and having to have the OS adjust the internal CMOS time over & over is a foolish, short-sighted decision made in the primordial ooze of the IBM PC.

    Time to enter into some semblance of a modern era.

    Oh – and preemptive counter-snark: Idiots who are confused by UTC have zero justification for being in the BIOS at all.

  14. Mordachai says:

    Likewise, one can still blame Microsoft for failing to do a reality check when it decides it should adjust the local clock. Why not, at that point, dial up Redmond and check: am I adjusting the local clock to the right (actual) time now, or to some goofy value. If goofy, don't adjust. If correct, adjust.

    [Because nobody would freak out if the computer spontaneously phoned home, right? -Raymond]
  15. TripShock says:

    Well, if you use Internet time in all the OSes, this is a non-issue, right?

  16. Joshua says:

    [So we all agree to blame CP/M? -Raymond]

    CP/M didn't auto-adjust the clock. Windows did, starting with Windows 95. Had the IsDSTActive bit been stored in the data bits of the MBR (there were a few still unallocated at the time), on the root of the primary partition, or in a spare bit in CMOS (I don't know if there were any) we would not have this problem today.

  17. Mordachai says:

    @Raymond – doesn't Windows default to synchronizing the clock with "internet time" anyway?

    Surely if that default is "on", Windows can make that check without freaking anyone out.  If "off" then don't check.  Seems like edge-cases are driving the decision making at Redmond, rather than the normal (majority) case.

    [Oh okay, tie it to that setting. But now you just launched a DDoS against the time server. Instead of spreading the load out evenly through the week, every computer hammers the time server at the same time. -Raymond]
  18. AndyCadley says:

    Storing the BIOS clock in UTC doesn't actually fix the issue, because leap seconds cause exactly the same problem but in a much more subtle and difficult to diagnose way. Ultimately any solution based on having the RTC in some kind of 'real world' clock is doomed to fail, replacing it with a monotonic counter independent of real world time is pretty much the only workable solution that avoids all the pitfalls.

  19. kinokijuf says:

    Regarding the bonus-readin: Maybe in the USA people call UTC „propeller-headed nonsense”, but here in Poland, we understand such things (And don’t mess with the BIOS).

  20. dave says:

    Here in the USA, the 24-hour clock is still an advanced concept, under military jurisdiction.

  21. David Totzke says:

    Thanks Raymond.  This explains why when I re-booted my laptop the clock was two hours fast last night.  Windows 7 had adjusted the clock and then Windows Server 2008 R2 helpfully did it again.

    I am, however, thankful for this as it alerted me to the fact that the clocks were changing yesterday.

  22. Joshua says:

    @AndyCadley: I fix leap seconds with time skew combined with internet sync. Since I don't need one second accuracy (even though I need one second precision) this works no matter how many operating systems are installed.

  23. JJJ says:

    My bios keeps the time in .beats. :/

  24. AndyCadley says:

    @Joshua: It fixes the "Is my wall clock right?" issue, more or less, but doesn't really solve all the issues like security logs, reliable time conversion etc that are raised by Markus Kuhn in the article linked by jas88. If anything they all become a lot more subtle (although arguably he's largely ignoring inevitable clock skew between machines in most cases anyway)

  25. John Elliott says:

    [So we all agree to blame CP/M? -Raymond]

    CP/M didn't even have support for a clock at the time MS-DOS was written.

    [Fine. The IBM PC BIOS? Why would a computer with only 16KB of memory waste it on time zones anyway? -Raymond]
  26. Deduplicator says:

    @AndyCadley, with regard to Joshua: Andy, you have computer hardware actually keeping time accurately enough that UTC leap-seconds are killing you? I want some of that. Joshua, why didn't you prechew that reasoning, someone is bound to need it? ;-)

  27. Gabe says:

    Heck, a machine with only 16k of memory probably doesn't even have a battery-backed clock anyway. I remember some computers used to ask you the date and time on every boot-up because there was no clock.

  28. AndyCadley says:

    @Deduplicator: The point is you don't actually solve the problems by switching to UTC, it's as flawed as using Local Time when it comes down to it. So you're better off sticking to Local Time and using the mechanisms already in place than trying to fix things by switching to UTC and just introducing new problems too.

  29. Joshua says:

    [Because nobody would freak out if the computer spontaneously phoned home, right? -Raymond]

    Answer a fool according to his folly, lest he be right in his own eyes.

    Do not answer a fool according to his folly, lest you become like him.

    (I am not calling Raymond a fool.)

  30. For machines set to sync via NTP, the daylight moving transition would be an obvious time to update, particularly if the machine was switched off over the transition point (which would also help server load by staggering it a bit) – that way, assuming the clock's more or less right, the system will know whether it's already been adjusted by an hour or not.

    Of course, just having a "summer time in effect" flag in the BIOS would have avoided this from the outset; there's a nice symmetry in using a time machine to fix a time-keeping problem… Switching to using UTC (and perhaps storing timezone offset too?) as part of the UEFI spec would have been nice, though.

    As Raymond explains, keeping the BIOS clock on local time is necessary in *some* cases (such as PCs dual-booting Win3.1), but on the non-PC architectures (MIPS, Alpha etc) Windows NT supported earlier, keeping it in UTC was necessary for similar reasons (dual-booting with OpenVMS or whatever) since those platforms tend to make the opposite assumption. So, the RealTimeIsUniversal registry entry was born: set to 1, Windows NT will treat the built in clock as being UTC rather than local time. With the loss of non-x86 support the feature was ignored and unmaintained for a while; Markus Kuhn has a web page about the UTC/local problem – http://www.cl.cam.ac.uk/…/ut-rtc.html – saying "Someone from Microsoft's Core Operating Systems Division hints in an email to me that both Vista SP2 and Windows 7 will fix the problems in the RealTimeIsUniversal=1". Microsoft Support say otherwise – support.microsoft.com/…/2687252 – "System may become unresponsive during Daylight Saving Time (DST) changeover if RealTimeIsUniversal is set" … "We strongly recommend that you not use the RealTimeIsUniversal registry entry. This issue does not occur if you do not use this entry."

    A co-worker had a laptop a few years ago where the time would suddenly become wrong by a few hours. He'd fix it, the time would be fine for a few weeks, then suddenly it would be wrong by hours again. Of course, it was set to use NTP, but with the wrong timezone; once a month, it would "correct" itself to show the time in New York, he'd manually change it to show time in New York as being the actual time in London, and everything would be nearly OK until the next sync.

    @Jean: Don't be too hasty there, the setting has some nasty gotchas at the moment! (I've told Markus so he can update his page with the disappointing news, and hopefully go and prod the guys next door again.)

  31. some computers used to ask you the date and time on every boot-up because there was no clock

    Or the battery died.

  32. Yuhong Bao says:

    "Heck, a machine with only 16k of memory probably doesn't even have a battery-backed clock anyway. I remember some computers used to ask you the date and time on every boot-up because there was no clock."

    AFAIK indeed the RTC was only introduced in the PC/AT.

  33. cheong00 says:

    I have better question: Why don't the DST patch check with NTP before patching the time?

    It should recognize the time would be out-of-range if patching again, if it try to contact NTP first. (If NTP is not accessible, then it's okay… there aren't reliable way to check as I understand)

    [As I already noted, that would result in a self-inflicted DDoS against the time server. -Raymond]
  34. Mihai says:

    Actually, there is a protocol for that: set bit 1 of byte 0Bh in CMOS.


    And it was around and documented for ages.

  35. Alex Cohn says:

    I would expect an OS that is up and running during the DST switch to undettake any necessary actions.

    But if it boots more than an hour later it should not perform changes to the system clock automatically. It could ask me at login time, it could check a time server – and not be a cause of DDOS because this boot will not happen simultaneously for many systems.

    Oh ***, it will! For many office machines this will happen first thing Monday morning, at 9 AM.

    Well, we can find a remedy. If the computer boots up every morning at 9 AM, set a flag "this is not likely to be a double-boot machine". Now it's safe to switch DST first thing in the morning. The OS will even have an additional hint: if every morning it boots at 9 AM, and on certain Monday it boots an hour earlier – that's time to apply DST.

    [I think you're over-engineering the problem. -Raymond]
  36. Gabe says:

    Yuhong Bao: Prior to the AT (which shipped with one), all RTCs came in the form of 3rd-party add-on cards. You would put something in your AUTOEXEC to read the current time and set the DOS clock from the proprietary RTC.

    Since there was no standard for how RTCs worked before that, it was the AT's designers' fault for not storing system time in UTC or providing a flag for DST (or correcting for DST).

  37. NoP says:

    Wasn't this one of your "I can't believe I had to write this"-posts, Raymond? If a user is advanced enough to use multiple operating systems on the same computer, why can't they configure it properly?

  38. Ben C says:

    I know I am late to the party, but I don’t see the issue.  It makes since to me that both OS’s would adjust the clock considering I have told both to via the option in the time zone setting dialog.  If I don’t want one OS to make the DST adjustment, I can go uncheck the box.

  39. [Not sure who "you guys" is, but that idea gets a +1 from me. You have to deal with the "it works on some machines but not others" confusion, though. -Raymond]

    If (flag exists and can be read) { do new stuff } else { do old stuff }

    AIUI from El Reg, the Linux people /HATE/ UEFI with a passion?

    Having never been in the situation described here, am I understanding it right that if I had a multi boot 8, 7, Vista, XP, 2k, ME, 98, 95, NT4, 2003 server, home server and 2k8 server, DST changes would make it add half a day to my clock? Time travel through multiboot? (Though, if this happened to me and I couldn't understand it, I'd probably end up throwing the PC at 88mph)

    [Right, the logic of the test is straightforward. The hard part is not confusing the end user. "It works on Bob's computer, but not on my computer. We are both running the same version of Windows. Is it because Bob's system is running French and I'm running German? Why do you hate Germans?" (Multiboot is become less of an issue nowadays anyway because people use VMs now.) -Raymond]
  40. Good point. I assume that any explanation message displayed in the Date/Time settings would also confuse users.

    "DST handling is improved with UEFI"

    "UEFI? What's that?"

    The old failsafe would seem to apply then: "If it isn't broken, don't fix it"

    We've lasted quite a while with this current behaviour, and as you say, it's a less common scenario any way.

  41. Deduplicator says:

    "UTC is as flawed as local time": Not really, the important aspects are there is only one UTC, and it doesnt have DST-switching. Adjustment-seconds don't actually signify, they are lost in the clock skew.

    "If it isn't broken, don't fix it": Well, it's broken for any multiboot scenario. And vm-scenarios only work with side-channel info regarding used timezone.

    Additional benefit for using UTC not local_time: You can inform all users upon logon/DST-change about the last DST-change, if there was one. It won't be lost because IT had to maintain the machine, or you share the machine with someone else.

    "We've lasted quite a while with this current behavior […]": It's tradition, don't touch it! It might be inefficient, it might be error-prone, it might have sharp edges, but I like manually correcting for those quirks.

  42. cheong00 says:

    [As I already noted, that would result in a self-inflicted DDoS against the time server. -Raymond]

    Actually, I have doubts on that thought.

    First, DST patch is only applied to computers with selected geographic location. If your setting in Regional Setting does not match, it will do nothing. That limits the number of computers need to run this.

    Second, the patch needs to be downloaded in order to run. If Windows Update servers can handle the load, why not time.windows.com? (I assume people in U.S. will not change this without good reason, such as having a local NTP server within coperate environment. Also, this would mean the patch will run 2 times: the first time will be when download is finished to determine whether it needs to run (check regional settings and NTP), the second time would be the scheduled time to change it to/from DST. )

  43. cheong00 says:

    Thinking that again, the second thought is flawed becasue in that case it won't cure the situation. The patch still need to query NTP at the "patch moment" or "next boot time" to make sure whether the time is already changed by other systems.

  44. martin langhoff says:

    It is 2012! Set RTC to UTC and lean a bit on NTP, every other OS modern has done it. It is the right thing to do. Declare RTC-in-localtime deprecated and unsupported, offer a hidden registry key to enable it.

    There is little risk of NTP traffic floods, NTP server infrastructure expects relatively frequent queries from nodes.

    Everyone hates flag days but some bits of legacy support are just not worth it.

    You have to bite that bullet at some point.

  45. On the other hand, setting the hardware clock to GMT means that BIOSes will need to have their own time zone setting or things like "turn the computer on every day at 8:00 AM" will be confusing.  But this seems like a tractable problem… until your local government changes the DST laws again and you have to update your BIOS…

  46. Worf says:

    I wonder if Apple got rid of their old "Clock Updater" utility… it's something that used to be installed on Intel Macs when you boot camped them to Windows – it switches the clock to local time for Windows, then switches it back to UTC for MacOS (and every other OS out there that keeps the BIOS clock at UTC).

  47. Cesar says:

    Even better than storing an "I already adjusted the clock for DST" flag in a UEFI variable: store the actual offset from UTC in a UEFI variable. Equivalent to storing the time in UTC, but without any compatibility problems with systems which expect to see local time. As a bonus, systems which set the RTC to UTC could write the offset as a zero to note that fact.

Comments are closed.