Wrong time by 7 hours... in the future?

[SD73]

So I've noticed an issue for the last few months.  I figure I'll run it past the usual suspects while I still have the chance.  My XP machine is a dual boot setup.  I usually run it in Linux Mint where I don't notice the problem.  However when I boot into XP on occasion it will have the wrong time by 7 hours in the future.  The timezone is setup correctly.  I've tried changing time servers and that does not appear to have helped.  I don't think it's the cmos battery as I haven't notice the problem while I'm in Linux.  After I do a re-sync with the Time Server it does get back on track.  Any ideas?

[i430VX]

I'm aware of this problem when i dual boot linux... windows stores in local time and linux stores in UTC which conflicts.
Unfortunately, I do not have a solution to offer.

Edited May 3, 2019 by i430VX

[SD73]

Well thanks.  At least for now I know I'm not going crazy.

[SD73]

1 hour ago, i430VX said:

I'm aware of this problem when i dual boot linux... windows stores in local time and linux stores in UTC which conflicts.
Unfortunately, I do not have a solution to offer.

I *THINK* I found the solution.  And it's thanks to you mentioning you have the same dual boot issue so I'll share this with you to see if the fix works for you as well if you'd like to try.  The info was at this link and listed as working with Windows 7.  It works for us old XP'rs as well it appears.  They also have a Linux sided solution but you'd have to repeat that procedure when Daylight Savings Time occurs.

https://www.howtogeek.com/323390/how-to-fix-windows-and-linux-showing-different-times-when-dual-booting/

 

1- Navigate to the following key in the left pane of the registry editor:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TimeZoneInformation

 

2- Right-click the “TimeZoneInformation” key and select New > DWORD Value.

 

3-Name your new value RealTimeIsUniversal.

 

4-Double-click the RealTimeIsUniversal value you just created, set is value data to 1, and click “OK”.

 

5- You’re now done, and you can close the Registry Editor. Windows will store the time in UTC, just like Linux does.

*If you ever want to undo this change, return to this location in the registry, right-click the RealTimeIsUniversal value you added, and delete it from your registry.

[LoneCrusader]

I've run into this a couple of times. Somewhere under your Linux Date/Time or Regional settings there should be a checkbox for "System Clock set to UTC." Clearing this should set Linux to the Windows-style behavior of setting the system clock to Local Time.

[SD73]

3 hours ago, LoneCrusader said:

I've run into this a couple of times. Somewhere under your Linux Date/Time or Regional settings there should be a checkbox for "System Clock set to UTC." Clearing this should set Linux to the Windows-style behavior of setting the system clock to Local Time.

Thank you.  I will have to check that out.  Even with the registry hack the above method reverted back to the wrong time.

[SD73]

9 hours ago, LoneCrusader said:

I've run into this a couple of times. Somewhere under your Linux Date/Time or Regional settings there should be a checkbox for "System Clock set to UTC." Clearing this should set Linux to the Windows-style behavior of setting the system clock to Local Time.

Unfortunately, Linux Mint 19.1 didn't have a little check that I could find.  I went with the procedure in the above link.

1-put the real time clock on the motherboard into local time. Linux will store the time in local time, just like Windows does:

    timedatectl set-local-rtc 1 --adjust-system-clock

2-To check your current settings, run:

    timedatectl

* If you ever want to undo this change, run the following command:

   timedatectl set-local-rtc 0 --adjust-system-clock

[LoneCrusader]

14 hours ago, SD73 said:

Unfortunately, Linux Mint 19.1 didn't have a little check that I could find.  I went with the procedure in the above link.

Glad you solved it. I forgot that the option may vary or even not exist under different desktop environments. I only use KDE3 or Trinity, which are not common these days.

[SD73]

Thanks for your input

10 hours ago, LoneCrusader said:

Glad you solved it. I forgot that the option may vary or even not exist under different desktop environments. I only use KDE3 or Trinity, which are not common these days.

Thanks for your input.  I'm glad it was solvable with a relatively easy fix.   It never occurred to me to make the Linux/Windows connection to the problem until I posted the question.

[cc333]

17 hours ago, LoneCrusader said:

I only use KDE3 or Trinity, which are not common these days.

I like those two DEs. They make sense, and also remind me of what it was like when I first dabbled with Linux way back in 2004 when I got a book with a copy of Fedora Core 2.

With Trinity, some minor tweaks and choice icon and theme packages, I can make a modern distro look very similar, if not identical, to FC2 since KDE 3 (one of two default choices; the other was GNOME 2) was the latest and greatest for quite some time, and Trinity is basically an updated version of it.

c

[Tripredacus]

My Windows 7 32bit PC at home has this issue, but my Windows 7 64bit PC doesn't. The 32bit PC has more updates in it than the 64bit, but I also know the CMOS battery in the 32bit PC is dead.

[UCyborg]

It seems Windows XP periodically reads raw RTC clock every hour without applying timezone adjustment, which it should if RealTimeIsUniversal is enabled. Same happens after resuming from standby / hibernation. The clock is correctly displayed only for 1 hour after boot, assuming PC doesn't go to standby / hibernation. I suppose no real fix exists for this problem if using UTC specifically is desired, which does strike me as more sensical.

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

https://oofhours.com/2020/10/07/windows-10-and-a-pcs-real-time-clock/

There's no problem with RealTimeIsUniversal setting on recent builds of Windows 10 (1809 at least) as far as I can tell. It was supposed to be corrected by Windows Vista SP2, though some sources indicate RealTimeIsUniversal value type had to be set to QWORD on 64-bit Windows builds rather than DWORD.

On 5/3/2019 at 7:13 AM, LoneCrusader said:

I've run into this a couple of times. Somewhere under your Linux Date/Time or Regional settings there should be a checkbox for "System Clock set to UTC." Clearing this should set Linux to the Windows-style behavior of setting the system clock to Local Time.

On 5/3/2019 at 4:35 PM, SD73 said:

Unfortunately, Linux Mint 19.1 didn't have a little check that I could find.  I went with the procedure in the above link.

On 5/4/2019 at 7:37 AM, LoneCrusader said:

Glad you solved it. I forgot that the option may vary or even not exist under different desktop environments. I only use KDE3 or Trinity, which are not common these days.

It can vary between distros with same desktop environment, eg. Manjaro with KDE5 has it, but KUbuntu doesn't.

On 5/3/2019 at 4:35 PM, SD73 said:

timedatectl

This exists on most common distros, at least those that use systemd. Some think systemd is an abomination and choose to use a systemdless distro, so there the procedure must be different.

It'd be nice if we could get old Windows to work with UTC properly somehow, though I imagine it would take some binary hacking.

Edited January 9, 2022 by UCyborg

[UCyborg]

Test booted into XP to see if the clock is correct after DST took effect and RealTimeIsUniversal is enabled. It is, but I guess it'll go back by 2 hours in about 1 hour.

Edit: It did.

Edited March 28, 2022 by UCyborg

[UCyborg]

Interesting, is it possible that keeping the time service running prevents the clock reset every hour when running normally (no standby / hibernation)?

[UCyborg]

I guess it is, though I haven't tested Windows' W32Time service recently, but the Network Time Protocol Daemon (ntpd) known from Unix world. A Windows port is distributed by MEINBERG and is available for download at https://www.meinbergglobal.com/english/sw/ntp.htm.

The hint why it helps partially at: How Microsoft Windows NT 4.0 Handles Internal Time

ntpd calls SetSystemTimeAdjustment during the normal operation with bTimeAdjustmentDisabled argument set to FALSE, which disables OS syncing hourly with RTC clock. If I understand the default config made by the installer, which is the combination of command line arguments and values inside configuration file ntp.conf, it makes the program sync quite frequently with NTP servers, minimum polling time being minimally 64 seconds and maximally 128 seconds and it's also checking if any network adapters have been added or disappeared at the interval of 3 seconds.

Looking at the Windows' default time service code in OllyDbg, it looks like it does call the API function with the argument as described above at some point, so it's possible that it would help with time resetting hourly, but not after coming out of standby since apparently the kernel code that syncs time with CMOS clock only does it right at initial boot, but subsequent sync doesn't compensate it for selected time zone and DST (if in effect).

It's also worth noting that due to incomplete/buggy implementation in the kernel, RealTimeIsUniversal=1 setting prevents the kernel from ever updating the RTC clock, so if the user or the service changes the clock, the change isn't reflected in RTC - reboot to BIOS settings where it can be seen the clock hasn't changed.

Edited May 14, 2023 by UCyborg