Fixing WSL2 Clock Drift After Sleep or Hibernation
The system clock inside WSL2 falls behind Windows' own clock, especially noticeably after your laptop sleeps and resumes. Here's why the VM's clock actually drifts, and how to force it back in sync.
WSL2’s internal clock falling noticeably behind Windows’ own system time — often by minutes, sometimes more — is a specific, well-understood consequence of its VM architecture, particularly after your host machine sleeps or hibernates.
Step 1: confirm the clock is actually drifted
date
# compare against Windows' own clock (system tray)Step 2: understand why this happens specifically after sleep/hibernation
WSL2’s Linux kernel runs inside a lightweight VM with its own internal clock, which doesn’t automatically track wall-clock time while the host machine is suspended — when your laptop sleeps for an hour and resumes, the VM’s clock can remain stopped at (or drift significantly from) the time it was at when suspension began, unless a resync mechanism catches up correctly.
Step 3: try the simplest fix first — restart the specific distro
wsl --terminate <DistroName>Terminating and relaunching just the affected distro (rather than a full wsl --shutdown) is often sufficient to force a clock resync without ending every other running WSL session.
Step 4: force a full WSL2 platform restart if the issue persists
wsl --shutdownThis tears down the entire WSL2 VM, including its internal clock state — relaunching afterward starts a fresh VM instance that resyncs its clock against the host at startup.
Step 5: manually force a time sync without a full restart
sudo hwclock -sOn distros where this is supported, this manually syncs the system clock from the hardware clock, which the WSL2 VM keeps closer to the actual host time than the software clock does drift-check against — a lighter-weight fix than a full restart in some cases.
Step 6: check whether your specific WSL2 version already includes automatic resync
More recent WSL2 versions have improved automatic clock resynchronization specifically targeting the sleep/resume scenario — running wsl --update to ensure you’re on a current version sometimes resolves recurring drift issues that were specifically fixed in a newer release.
Step 7: understand why this specifically matters for certain workloads
Clock drift causes subtle but real problems for anything relying on accurate timestamps — TLS certificate validation (which checks certificate validity windows against the current time), authentication tokens with expiration times, and build systems that compare file modification times can all behave incorrectly when the WSL2 clock has drifted meaningfully from actual wall-clock time.
Step 8: verify the fix held after your next sleep/resume cycle
Since this issue is specifically triggered by suspension, confirming a fix requires testing across an actual sleep/resume cycle, not just checking the clock immediately after applying a fix — a fix that resolves drift once might not prevent it from recurring after the next suspension if the underlying resync mechanism itself wasn’t what actually changed.
Why this is a VM-architecture issue, not a WSL-specific bug
Clock drift following host suspension is a known characteristic of virtual machines generally, not unique to WSL2 — any VM’s internal clock can drift relative to host wall-clock time across a suspend/resume cycle unless specifically corrected, making this a predictable consequence of WSL2 running inside a real lightweight VM rather than an unusual defect.