Wrong time in Windows – Reader observations

[German]In Windows there seem to be problems with the synchronization of the internet time lately. after a problem at the end of march a short addendum to this topic.

At the end of March 2020 I had reported in the article Windows 10: Issues with daylight savings time switch in 2020? about issues of some users with the automatic time changeover by Windows. Now a supplement in the form of two user messages, which told me about their observations. I simply set the observations as they were reported to me.

Strange behavior of Windows 7

Blog reader Wilfried L. is still working with Windows 7 and has been animated by the above post to share his observations. He wrote:

in view of your blog posts about issues with the changeover to daylight saving time and the many comments I would like to point out my puzzling observations on the one hour late clock in Windows 7 (Home Premium SP1 32bit). Perhaps there is a connection.

Thanks to the wristwatch I don't actually use and display the time on my computer, but I've been observing wrong time settings since December 2019. First I noticed wrong times in mail headers. Sometimes the time changed during a session after one or more hours to the correct one, also sometimes after an update of Windows, after restart it could, but did not have to be wrong time value again – I found no system to detect what caused that behavior.

Time zone, change between summer and winter time and synchronization over the internet with a time server were set correctly. Changing the time server only helped temporarily.

The clock was one hour slow in winter, and it stayed that way after the start of summer time. Even crazier: after disabling synchronization with a time server and setting it manually, the clock was two hours slow the next day, and this was repeated even if there was no Internet connection in Windows in the meantime. Under Linux (Dual Boot) the time is correct. Another, less used, computer seems not to be affected. So Windows must be the root cause.

Already on 24. March 2018 (one day before the change to daylight saving time) I had to observe something like this with a faulty recording timer. In the time settings it was claimed shortly afterwards that the time had been synchronized (as scheduled) on 3/25/18 at 8:19, and "Update Now" led to the message: "Error determining the status of the last synchronization. The interface is unknown." As a result, I had successfully switched the time server from time.windows.com to time.nist.gov.

All in all, Microsoft's time servers seem to cause problems from time to time.

This behavior can be explained. Linux assumes the time stored in the hardware clock as UTC by default, but Windows always assumes local time. The difference between UTC and local time is one hour (CET) or two hours (CEST) here in German. So if you switch between Linux and Windows, it is logical that the clock is always adjusted or it takes a while to correct it. If you want to prevent the clock from switching back and forth, you either have to set Linux to accept local time in the hardware clock as well, or tell Windows to accept UTC. There are instructions on the net, how to do this.

Feedback from Andi

I also received feedback from German blog reader Andi O. about time synchronization under Windows. Andi also refers to my above article and writes.

In the comments [to my article about issues with daylight saving time switch mentioned above] it had worked sometimes, sometimes not. I took this as an opportunity to see what the state of affairs is in my [Windows 10] 1909.

I set the startup type of the timer, restarted the computer, and then tried to start the timer with the command prompt.

Note: My account for the test was Administrator. If the startup type of the timer is set to "Disabled", an error message appears and the timer refuses to work. See the screenshot "Error message timer disabled".

The situation is different for "Manual". You might think that with "Manual" the timer can always start. But this is not quite true. If I open the command prompt via the context menu "As Administrator", the timer starts, see screenshot below.

But if I open the command prompt normally, the timer is blocked. See screenshot below.

So with Windows 10 version 1909, the timer will block the startup type "Manual" from the User Account Control. Synchronization only works if you run it manually yourself, or if you have a local user.

The explanation here: Deactivated services cannot be started by any user or admin. This issue could also be solved by setting the startup type for w32time service to Automatic (or Automatically delayed).