none
RealTimeIsUniversal bug in Vista

    Question

  • Hi all,

    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?

    Cheers

    - Balt

    Thursday, March 22, 2007 4:54 AM

All replies

  • Hi Balt:

     

    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.

     

    Regards,

     - Mark Hopkins (MSFT)

     

    Thursday, March 29, 2007 5:12 PM
    Moderator
  • Mark,

     

    I have tried to implement RealTimeIsUniversal in my Vista 64-bit Business implementation and it doesn't work. Specifically I added:

     

      HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal

    to my registry. Is realtimeuniversal supported in Vista? Is it supported in Vista 64-bit? Are there any bugs with it? Thank you - jl

    Monday, November 19, 2007 9:53 PM
  • Hello 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.

     

    Sincerely,

     

    Eliot - MSFT

    Wednesday, November 21, 2007 9:35 PM
    Owner
  • Hi JL.

     

    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.

     

    Sincerely,

     

    Eliot - MSFT

    Monday, December 03, 2007 7:20 PM
    Owner
  • Seems that this does not work when you sleep the system. When resuming from sleep, the time is off. For example when I boot the machine the time is 2:00pm and when I then sleep/resume the time is now 9:00 pm.....
    Tested on Vista SP1 64bit.

    Olivier
    Thursday, March 27, 2008 9:10 PM
  • It doesn't work properly. It works upon Vista boot but an hour later an uptime message from Event Log (ID 6013) set the universal time to local time. If the clock is resynced then the same thing will happen 2 hours after boot.

     

    Sunday, March 30, 2008 10:29 PM
  • I'm having the same problem.  I am going to open a ticket with Microsoft so they can finally fix this in a future service pack or whatever.  I will have my MacBook Pro long enough so I will benefit from a UTC hotfix.
    Friday, October 31, 2008 1:39 AM
  • Hi, all,
    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.
    Thursday, February 12, 2009 8:54 AM
  •  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?

    Thank you,

    PedroT
    Tuesday, February 24, 2009 12:52 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.

    Thanks.
    Saturday, February 28, 2009 10:56 PM
  • This did not seem to fix the issue. Am I missing a step? 
    Saturday, March 14, 2009 11:33 PM
  • I found this site which describes the sources of the problem -- for those interested in more details:

    http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html

    Sunday, March 15, 2009 5:47 AM
  • Yes, it does require setting the registry key and setting the time under MacOS. After that, once you sart (or resume) Windows the clock should be correct and in sync.
    PedroT
    • Proposed as answer by hohepa04 Tuesday, July 07, 2009 1:01 AM
    Monday, March 16, 2009 1:14 PM
  • This problem has been fixed in Windows 7 RC. When returning from sleep, clock stays at the incorrect time for a split second then changes to the correct time.

    Tuesday, July 07, 2009 1:04 AM
  • 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.

    Pedro


    PedroT
    Tuesday, July 07, 2009 12:47 PM
  • 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)

    Eric Gillespie

     

    Tuesday, June 29, 2010 2:23 AM
  • Hi Eric,

    I am sorry but the fix for this reg-key is only available in Win7 and Vista SP2.

    Cheers


    PedroT
    Friday, July 16, 2010 11:49 PM