Time sync and the dual-boot UTC trap

Verified 2026-10-292 min read

Fix a clock that drifts or is 8 hours off, understand w32tm, and stop dual-boot from resetting your time zone.

Tested onPro (26H2) / Server · Build 26300.9457 / 26100.33650 · x64

Build: 26300.9457 / 26100.33650
Edition: Pro (26H2) / Server
Architecture: x64
Support: Documentation (E1)
Evidence: E1Official documentation
Verified: 2026-10-29
Page type: Troubleshoot

The short answer

Two different failures look the same:

Symptom	Cause
Clock drifts slowly (minutes per week)	time sync broken — wrong server, blocked port 123
Clock is exactly N hours off, every boot	dual boot writing the RTC differently (Windows local time vs Linux UTC)
Time correct, time zone wrong	time zone setting, not sync
Time jumps on wake	sync running at resume, not before

The exact-hours case is not a sync problem at all, and running w32tm /resync will not fix it.

Diagnose

w32tm /query /status
w32tm /query /configuration | Select-String 'Type|NtpServer|Enabled'
w32tm /stripchart /computer:time.windows.com /samples:3 /dataonly
Get-TimeZone | Select-Object Id,DisplayName,BaseUtcOffset

Reading w32tm /query /status:

Source — time.windows.com (public), your DC (domain), or Local CMOS Clock (not syncing).
Last Successful Sync Time — if it is days old, sync is failing.
Poll Interval — how often it retries.

Source: Local CMOS Clock means the machine is trusting its own hardware clock and drifting.

Fix sync

# point at a reachable NTP server and resync
w32tm /config /manualpeerlist:"time.windows.com,0x9" /syncfromflags:manual /update
Restart-Service w32time
w32tm /resync /force
w32tm /query /status

If it still fails, check that UDP 123 outbound is not blocked (corporate networks often block it), and try another server.

On a domain, do not point members at a public server — they must follow the domain hierarchy (/syncfromflags:domhier).

The dual-boot UTC trap

Windows stores the hardware clock in local time by default; Linux stores UTC. When one OS writes the RTC and the other reads it, the clock is off by exactly your UTC offset — 8 hours in China, 5 in New York, and it changes with daylight saving.

Two fixes:

A. Tell Windows the RTC is UTC (recommended for dual boot):

reg add "HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /t REG_DWORD /d 1 /f

Then reboot. Windows now agrees with Linux.

B. Tell Linux to use local time (equivalent, less clean):

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

Pick one. Doing both re-creates the offset.

Time zone vs time

Set-TimeZone -Id "China Standard Time"
# and make sure automatic time zone is not fighting you
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\tzautoupdate' -Name Start -ErrorAction SilentlyContinue

“Set time zone automatically” is useful on a laptop that travels and harmful on a desktop behind a VPN — the geo-IP lookup can put you in the wrong country.

Why any of this matters

TLS certificate validation fails with a wrong clock — “your connection is not private” on every site.
Kerberos rejects authentication beyond a 5-minute skew (domain machines).
File timestamps in backups and logs become misleading.
2FA/TOTP codes are rejected.

Lab boundary

E1. Time service behaviour is documented by Microsoft. The lab VMs sync from the Proxmox host clock, so no drift or dual-boot offset was reproduced.