What's happening
You wake your laptop from sleep, open WSL2, and run apt-get update. It fails with:
E: Release file for http://archive.ubuntu.com/ubuntu/dists/jammy-updates/InRelease is not valid yet (invalid for another 7h 23m 12s). Updates for this repository will not be applied.
Or git pull throws an SSL certificate error — "certificate is not yet valid." Same root cause: WSL2's clock is stuck in the past.
Here's what happens under the hood. When Windows sleeps or hibernates, the WSL2 VM pauses entirely. On resume, the Linux kernel has no idea how much time passed — it picks up exactly where it froze. Sleep for 7 hours and your WSL2 clock is 7 hours behind. Any tool that checks timestamps breaks: apt-get, git over HTTPS, curl, TLS handshakes — all of them.
Quick fix (one command)
Copy the Windows hardware clock into WSL2's system clock:
sudo hwclock --hctosys
Run date before and after to see the jump:
date
# Thu Jun 18 03:21:45 UTC 2026 ← hours behind
sudo hwclock --hctosys
date
# Thu Jun 18 10:47:02 UTC 2026 ← correct
Then retry apt-get update. The "not valid yet" error should be gone.
No hwclock? Use ntpdate instead:
sudo apt-get install -y ntpdate
sudo ntpdate time.windows.com
Nuclear option: restart WSL2 from PowerShell. Windows resets the VM clock on startup, so this always works. Save open work first.
# Closes ALL WSL sessions
wsl --shutdown
Reopen your WSL2 terminal and the clock will be correct.
Verify it worked
# Check the clock
date
# Re-run the failing command
sudo apt-get update
# Or for git
git pull
No "not valid yet" in the apt-get output means you're good. For git, a clean pull or fetch confirms SSL is happy again.
Permanent fix — stop it coming back
Typing sudo hwclock --hctosys every time your laptop wakes up gets old fast. Pick one of these based on your Ubuntu version.
Option 1: Enable systemd (Ubuntu 22.04+ — recommended)
Ubuntu 22.04 and later support systemd inside WSL2. Once enabled, systemd-timesyncd handles NTP sync automatically — you never have to think about the clock again.
Add this to /etc/wsl.conf:
sudo tee -a /etc/wsl.conf <<EOF
[boot]
systemd=true
EOF
Restart from PowerShell:
wsl --shutdown
Reopen WSL2 and confirm the sync service is running:
systemctl status systemd-timesyncd
You want active (running). That's it — clock drift is handled from here on.
Option 2: Auto-sync on shell startup (Ubuntu 20.04 / no systemd)
Drop a silent hwclock call into your shell startup file so it fires every time you open a terminal:
# Add to ~/.bashrc or ~/.zshrc
if [ -n "$WSL_DISTRO_NAME" ]; then
sudo hwclock --hctosys 2>/dev/null || true
fi
To skip the password prompt, give your user passwordless sudo for hwclock only:
sudo visudo
Add this line at the end (swap yourusername for your actual Linux username):
yourusername ALL=(ALL) NOPASSWD: /sbin/hwclock
Every new terminal now syncs the clock silently before you type your first command.
Option 3: Install chrony for precision (TLS debugging, Kerberos, distributed systems)
For work where milliseconds matter — cert debugging, Kerberos authentication, anything coordinated across distributed nodes — chrony is more resilient than a one-shot hwclock:
sudo apt-get install -y chrony
sudo systemctl enable chrony
sudo systemctl start chrony
Check it's tracking correctly:
chronyc tracking
Good output shows Leap status: Normal and a System time offset in the milliseconds range. Seeing seconds instead of milliseconds? Sync is still converging — wait 30 seconds and check again.
Why WSL2 and not WSL1?
WSL1 ran Linux syscalls directly on the Windows kernel. It always used the Windows system clock — drift wasn't possible.
WSL2 is a different beast. It runs a real Linux kernel inside a lightweight Hyper-V VM. Sleep the machine and that VM pauses cold. On resume, Windows doesn't tell the VM how much time elapsed, so the Linux clock is simply wrong.
This is a documented WSL2 limitation. The hwclock and NTP approaches above are the established workarounds. The WSL team has been working on automatic clock correction at resume time, but until that ships, manual sync or systemd is the reliable path.