# Time sync and the dual-boot UTC trap

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

**Tested on**

- Build: 26300.9457 / 26100.33650
- Edition: Pro (26H2) / Server
- Architecture: x64
- Evidence: E1
- Verified: 2026-10-29

## 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

```powershell
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

```powershell
# 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):

```powershell
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):

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

Pick one. Doing both re-creates the offset.

> **Caution: RealTimeIsUniversal and Fast Startup**
>
> With Fast Startup enabled, the hibernated kernel may not re-read the RTC on resume, and the setting can appear not to work. Test with a full restart (`shutdown /s /full`), and consider disabling Fast Startup on dual-boot machines — see [sleep, hibernate and Fast Startup](https://winbook.fyi/en/windows/perf/sleep-hibernate-faststartup/).

## Time zone vs time

```powershell
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.

## Related

- [Sleep, hibernate and Fast Startup](https://winbook.fyi/en/windows/perf/sleep-hibernate-faststartup/)
- [Remote Desktop host setup](https://winbook.fyi/en/windows/remote/rdp-host/)
- [Dual boot](https://winbook.fyi/en/windows/install/dual-boot/)

## 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.

## Sources

- [Microsoft Learn — Windows Time Service tools and settings](https://learn.microsoft.com/en-us/windows-server/networking/windows-time-service/windows-time-service-tools-and-settings)
- [Microsoft Learn — How the Windows Time Service works](https://learn.microsoft.com/en-us/windows-server/networking/windows-time-service/how-the-windows-time-service-works)
- [Microsoft Learn — Quick Assist](https://learn.microsoft.com/en-us/windows/client-management/quick-assist)

---

Source: https://winbook.fyi/en/windows/customise/time-sync/