Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I dual boot Linux and Windows XP on my laptop. I added the following registry key in XP to support Universal Time from the BIOS:

HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal

The clock is set correctly when I start up XP, but if the machine wakes from sleep, the clock is off a couple hours.

Is there a way to have XP use the Universal Time setting correctly during wake up? If not, can I prevent XP from setting the clock on resume?

share|improve this question

3 Answers 3

My guess is that Windows somehow misbehaves upon wakeup from sleep regarding the system time. According to a Wikipedia article the registry key you are citing doesn't fully work, even on recent versions of Windows:

Windows expects the real-time clock of the computer to run on local time. Since Windows NT there has been a registry entry RealTimeIsUniversal=1, but this feature is not supported or fully implemented yet (including Vista), so it is not possible to run the real-time clock on Coordinated Universal Time.

I think your best bet here would be to tell Linux that the system clock runs in local time and bite the bullet two times a year with DST.

ETA: This article details the problem a little more and also hints on the fact that the issues with that registry key are fixed in Vista SP2 and Windows 7:

2001-07-09: I got a reply from someone in Microsoft's Base Kernel Team who got interested in RealTimeIsUniversal and they had a look at the relevant parts of the NT kernel source code. The RealTimeIsUniversal flag is there (a leftover from the days when NT still ran on RISC machines with UTC RTCs), but its implementation seems now incomplete and it is currently not covered by Microsoft's documentation and regression test suite, therefore using it is not recommended at this time. A couple of potential RealTimeIsUniversal bugs have been identified over the past few days, there might be more. For instance, the kernel debugger assumes that the CMOS time is local time and will get the time wrong when RealTimeIsUniversal=1. There might be a similar problem in the code that resumes processing after the CPU was suspended or in the code that calculates DST change times.

2008-10-31: Hurray! 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 support that have made running the CMOS clock in UTC so far not practical with Windows (i.e., the time was wrong after resuming a suspended/hibernating Windows). He warns though that this improved support for UTC in the CMOS clock may not immediately be widely documented and details may change in the future.

So, concluding I think you have two options:

  1. Upgrade to a recent OS.
  2. Switch Linux over to local time.


P.S.: Contrary to other posters here, this can't be the CMOS battery. The real-time clock isn't powered by the battery as long as the system has power. This includes sleep mode (obviously). In case the CMOS battery is dead the real-time clock would reset itself to its factory settings which is usually January 1 a few years back. A couple of hours offset simply doesn't happen, as there is no clock "state" that survives a complete power loss. It's not akin a wall clock with a flaky battery which retains its time even when the battery is dead.

share|improve this answer

If the time is correct when you boot (because it's being synced), and is correct as long as Windows is there to advance it, but doesn't advance when Windows is asleep, then most probably you should check the CMOS battery.

share|improve this answer
    
If the CMOS battery is dead then the clock resets itself to way back. However, this would only happen if you phyically cut power to the computer. –  Joey Oct 18 '09 at 18:34
    
IMHO Windows doesn't forget the current time when asleep. The hardware clock simply doesn't advance. You're confusing sleep with reboot. –  harrymc Oct 18 '09 at 19:06
    
The hardware clock advances by itself, as long as it has power. This is not something that the operating system does. Windows, however, relies on the RTC only upon startup and keeps the time itself anyway. So whenever the RTC and Windows' own timekeeping are out of sync (startup, waking from sleep/hibernation) it has to update its own clock. And that's where bugs lie; see the article I linked in my answer. –  Joey Oct 18 '09 at 20:47

It doesn't sound like the CMOS battery as it usually resets time to a fixed date rather than being "off a couple of hours".

Another temporary solution is to install something like Atomic Clock Sync and set it to "Auto Synchronize Daily". This will bring the clock back into line.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.