W7 advances clock multiple times after DST

[metalbunny]

On the 25th of March we switched to DST here in Denmark and Windows correctly advanced the clock 1 hour at 2 am like it was supposed to. Then today it added another hour to the clock so I had to set it back to the correct time manually.

This weird behaviour started happening 2-3 years ago after a Windows update to the DST settings. When we go into DST it will set the clock on the correct date, then a few days later it will add another hour, and then after a few days more it will set the clock again. When we return to normal time (CET) in the fall it's the same issue - it will set the time on the right date, and then take another hour of a few days later. Each time it happens 2-3 times before it stops changing the time for no reason.

It only does this around the DST forward/backwards dates. Once I reset the clock manually it sticks. The time zone is set right, the clock is right otherwise, it's set to auto-adjust time from time.windows.com.

There are two event log entries whenever it changes the time, but in this case this part is different:

Previous Time:        ‎2018‎-‎04‎-‎05T08:09:41.281252600Z
New Time:        ‎2018‎-‎04‎-‎05T07:09:39.000000000Z

Previous Time:        ‎2018‎-‎04‎-‎05T07:09:39.000000000Z
New Time:        ‎2018‎-‎04‎-‎05T07:09:39.000000000Z

The rest of the entries are normal.

There are two entries each time it changes the clock and it "blames" the Windows Time Service for setting the time each time, but I cannot find any entries that mention the DST. There's only one entry for time sync in the task scheduler (unless it's buried in the wrong place) and that's set to run each Friday - so not in the middle of the week.

This is Windows 7 Home SP1 (US/UK English Windows with Danish Locale settings). According to Windows Update it's fully updated.

 

[Snick]

Hi metalbunny,
This weird behavior started happening 2-3 years ago after a Windows update to the DST settings.
If you know what KB you referred to, you can uninstall the update and hide it.

 

[metalbunny]

Hi metalbunny,
This weird behavior started happening 2-3 years ago after a Windows update to the DST settings.
If you know what KB you referred to, you can uninstall the update and hide it.

I don't know the exact number anymore and I'm not entirely certain that's what caused it, I just don't know what else would. There have been several updates that changes the DST settings for various time zones since, but it hasn't fixed this weird behaviour.

I changed the Windows time server to dk.pool.ntp.org after the OP to see if it makes a difference. So far the clock hasn't gone wrong, but until we switch back to CET in October I won't know for sure if this solves my problem permanently.

 

[Paul Black]

Hi metalbunny,

These are some of the updates for changes in Windows 7 for Time Zone:

KB3112148: December 2015, cumulative time zone update.
KB3077715: August 2015 cumulative time zone update
KB3013410: December 2014 cumulative time zone update.
KB2998527: September 2014 time zone update for Russia.
KB2981580: August 2014 cumulative time zone update.
KB2922717: Time zone changes for Jordan, Brazil, and Fiji.
KB2904266: December 2013 cumulative time zone update.
KB2863058: August 2013 cumulative time zone update.
KB2779562: December 2012 cumulative time zone update.
KB2756822: October 2012 cumulative time zone update.
KB2660075: Time and date if the time zone is set to Samoa.
KB2633952: December 2011 cumulative time zone update (supersedes/replaces update 2570791 rel August 2011).
KB3148851: Time zone changes for Russia.

I hope this helps!

 

[bendipa]

The problem lies with Windows not operating on UTC, I had the same issue here in the UK when the time changed on the same date and clocks went forward by an hour from GMT to BST. To adjust the time zone to UTC, open up the registry, then browse to HKLM>System>ControlSet001>Control>TimeZoneInformation.

Make a new binary value in right pane called RealTimeIsUniversal, and give it a value of 1. Close the registry and adjust your time in Windows to whatever it is now. Your hardware clock (in BIOS) should be 1 hour behind.

 

[Snick]

bendipa, is this the same issue as linux/win7 dual boot changing times?

 

[metalbunny]

The problem lies with Windows not operating on UTC, I had the same issue here in the UK when the time changed on the same date and clocks went forward by an hour from GMT to BST. To adjust the time zone to UTC, open up the registry, then browse to HKLM>System>ControlSet001>Control>TimeZoneInformation.

Make a new binary value in right pane called RealTimeIsUniversal, and give it a value of 1. Close the registry and adjust your time in Windows to whatever it is now. Your hardware clock (in BIOS) should be 1 hour behind.

This raises the question of how NTFS deals with UTC. Would it assume the current time stamps are in UTC or what does it do? Because it seems like things could get a little "funny" with the backup when there's a few million files that have never had UTC timestamps. Unless what it tells me and what it tells the programs are two different things.

I use SyncToy for backup, but I don't actually know if it looks at the timestamps or just goes by the "A" attribute.

 

[bendipa]

bendipa, is this the same issue as linux/win7 dual boot changing times?

I believe so, and funnily enough I do have both systems, both of which now synchronise with the correct time. But the important thing is that the Windows side was the clock to correct, not that of Linux.

This raises the question of how NTFS deals with UTC. Would it assume the current time stamps are in UTC or what does it do? Because it seems like things could get a little "funny" with the backup when there's a few million files that have never had UTC timestamps. Unless what it tells me and what it tells the programs are two different things.

I use SyncToy for backup, but I don't actually know if it looks at the timestamps or just goes by the "A" attribute.

I don't use Synctoy so have no idea there. I wrote my own script for data backups based on xcopy, and that works on the archive attribute.