This Question is mostly for other people to learn from and to satisfy my own curiosity if someone knows why it does the following.

We had a problem with our DC not having the right time due to it being virtualized, that has since been fixed. But some of our clients and servers needed the updated time. So I tried running the following commands as admin w32tm /query /source to make sure it was getting the time from our Domain Controller then w32tm /resync to sync the time, both commands had no errors but the time didn’t change.

I see something similar to the following line in the event logs. The system time has changed to 2014-09-08T21:31:33.328000000Z from 2014-09-08T21:31:33.342455400Z.

So I try the command a few more times with no change and go search around on Google for a bit, only to come back and find the client has the right time now, but nothing new in the event logs.

I tried on a second client with the same result but I didn’t leave the client but poked around the logs a bit and out of pure luck I looked down at the clock and noticed that time was getting closer to the real time. It was slowing drifting back to the right time. Every now and then the clock would go up by 2 seconds, or a second would change to the next digit before a whole second had gone by. It would do this until the clock had reached the right time.

My question is why does it do this? why not just change the time to the correct time instantly like my personal computer does when I sync the time to an NTP server?

  • CHmmond, I'm with the same problem with the virtualized DC, could you point me how you solve the problem? thanks!
    – Gustavo
    Commented May 19, 2017 at 8:22
  • I have just discovered that my personal workstation (Windows 10 Enterprise 20H2) does the same.
    – Ubeogesh
    Commented Jun 14, 2021 at 7:18

1 Answer 1


Apparently this is by design:

If the local clock time of the client is less than three minutes ahead of the time on the server, W32Time will quarter or halve the clock frequency for long enough to bring the clocks into sync. If the client is less that 15 seconds ahead, it will halve the frequency; otherwise, it will quarter the frequency. The amount of time the clock spends running at an unusual frequency depends on the size of the offset that is being corrected


I can't find a reference that explicitly explains WHY it is designed so, but I would guess that the aim is to avoid sudden jumps in case other applications are using the internal clock to time operations. So if the offset is low then the 'convergence' method is used by adjusting the local clock rate. If the difference is 3 minutes or greater then the risk of Kerberos authentication failing (>5 minutes clock diff) is considered more serious than the risks involved in 'jumping' the local clock, so the clock is just reset rather than converging

  • You learn something new every day!
    – Alex Berry
    Commented Jan 2, 2015 at 15:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .