I have a strange problem: On my MacBookPro I run both Vista and OSX. It's an old known fact that Windows (not even Vista) do not keep UTC in the realtime clock like every other real operating system does.
Turns out that by adding the registry key RealTimeIsUniversal=1 to the TimeZoneInformation bit of the registry, this problem can be solved between reboots.
But whenever Vista goes to sleep, the time reverts to UTC when woken. Looks like a bug to me. I wish MS would have an official bug report facility (rather than a pay per incident support)
Any idea how that can be resolved?
This forum is for the discussion of programming issues on Windows Vista. I'm not sure you'll be able to find support for running Windows Vista on your Macintosh, but you might try posting your question at http://support.microsoft.com.
- Mark Hopkins (MSFT)
I have tried to implement RealTimeIsUniversal in my Vista 64-bit Business implementation and it doesn't work. Specifically I added:
to my registry. Is realtimeuniversal supported in Vista? Is it supported in Vista 64-bit? Are there any bugs with it? Thank you - jl
I am trying to find someone who has the exact answer to your question. Unfortunately, communication is a little tough yesterday and today, as many people are out on holiday.
I don't want you to think we haven't heard your question. It just may take until after the weekend to find a live person.
I appreciate your patience and will get this answered as soon as I can.
Eliot - MSFT
Here is what I got from our developers. I hope that something in here answers your question. We are not aware of any bug in regard to this, but as you see, you may have discovered one.
From the team:
RealTimeIsUniversal is included. The feature has no 32-bit / 64-bit-ness so 64-bit shouldn't be affecting it that I know of. BUT, the boot path is complicated and maybe there is a bug here.
What this key changes is how the kernel interprets the Real-Time Clock (RTC) from the motherboard and how it keeps it synchronized when a user/application (like the NTP service) changes the system time. Note that the BIOS does not have a "time zone setting" one can set. It's up to the OS to keep track of this.
When this feature is enabled, the RTC will be interpreted as UTC time. This means setting the clock to something other that UTC time will cause "local time" to be wrong. Luckily, just setting the time in the time\date CPL will "fix" this for the user.
When activated, it requires a reboot or hibernate/resume to take affect. AND THEN you need to set your current local time to the right time to force the kernel write out the system time in UTC to the RTC.
That said, I haven't tried it while hibernating and resuming. It's mostly used on servers that stay up 24/7.
Also, if you are dual-booting, all bets are off. The two OSes can't talk to each other so their interpretation of the RTC and thus how they write out the time to them will mess each other up.
There's a lot there, and as I said, I hope this helps you. Please let me know if you need further clarification.
Eliot - MSFT
I got same problem, both in windows XP and XP 64。When I update something and turn off my computer, the clock changed. I guess that when normally shutdown, it test whether RealTimeIsUniversal is true and then set hardware clock. But when turn off and install update, maybe forget this test.
When suspend/resume on XP 64, the clock will change!!! Maybe system clock was directly write to hardware, please take a look.
This setting has been revised under Windows Vista SP2 (RC), Windows 7 (Beta) and Windows 2008 R2 (Beta). Could early adopters try it out and provide comments/feedback?
- Proposed as answer by Pedro Miguel Teixeira Tuesday, February 24, 2009 12:55 AM
I dual boot Windows 7 beta and Leopoard 10.5.2, and have this issue. I am going to try this fix, but I am not very experienced with regedit. Do I simply add a new string named "RealTimeIsUniversal," right click to set value to "1," and save & reboot? Does it need to be in any order, or simply add it at the end.
There should be no "split second" incorrections or any other time jump anymore unless your CMOS is wrong (not set to UTC actually).
If your CMOS clock is incorrect then you might resume from sleep with the wrong time. NNTP will quickly correct that but this is still not where you want to be.
Let me clarify how this should be used:
1 - Edit the registry to include this option;
2 - Shutdown Windows and start your alternate OS (e.g. MacOS);
3 - Set the time right;
4 - Shutdown your alternate OS and boot Windows;
5 - Sleep and resume from sleep Windows
From step 3 on, your clock shouls always be correct, for both OSes, even when you are offline with no chance to get your clock updated by an external source.
- Proposed as answer by Pedro Miguel Teixeira Thursday, April 22, 2010 1:21 AM
I personally find (as I use hibernate a lot) that on an XP (SP3) system, whether Pro or Home, the option doesn't take after a resume from hibernated state. I have tested resume-from-hibernation after another operating system has its reins on the computer, and I've tested resume-from-hibernation directly after a power up. In both cases, I generally (as in about 98% of the time) find that the time will correct itself to UTC in each case, instead of being corrected to my local time (NZST; UTC+12). However, Windows just surprised me. I'd booted up to Linux to view this article, then decided to check the Windows clock again... now the clock is correct. I've resorted to turning on Internet Time Syncronising, and set the interval to every ten minutes. Way too short, but I'm sick of converting the time manually all the time.
I really want a cure to this particular issue, and I understand that a developer's hotfix actually corrected this issue. However, that hotfix is about as easy to find as a new copy of Windows 95.
Any further suggestions? I run multiple machines here, three of them run Windows in some form or other. My thanks for any answers.
Cheers, The Viking (Dr Smokey)