WSL2 Time Drift: Fix Clock Skew the Right Way

February 20, 2026 • February 20, 2026 • Read: 22 min • Views: 0

Was this helpful?

When WSL2 time drifts, nothing fails politely. Git fetches die with TLS errors. Package managers swear the repository metadata is “from the future.” Logs become fiction. And your incident timeline—already fragile—turns into interpretive dance.

The worst part: it feels random. You close your laptop, walk to a meeting, come back, and suddenly your Linux environment believes it’s last Tuesday. Let’s fix it like adults: measure first, sync the right clock, and stop papering over skew with hacks that make security tools scream.

What WSL2 time drift looks like (and why you should care)

Clock skew is one of those “it’s only a few minutes” problems that can stop an entire pipeline. In production operations, time is an API contract: TLS certificate validity, Kerberos tickets, OAuth token expiry, log correlation, distributed tracing spans, cache invalidation, build reproducibility. Break time and you break trust.

WSL2 adds a twist: it’s a Linux VM running under Hyper-V virtualization plumbing, with its own kernel. That means time can drift at the guest level even when Windows looks fine. Sleep/hibernate transitions and host load can exacerbate it. Some users get a WSL2 instance that resumes with a stale clock; others see periodic drift under sustained CPU pressure or when the guest isn’t getting scheduled frequently.

Two quick realities:

Your Windows clock being correct does not guarantee your WSL2 clock is correct.
Fixing time by “just setting the date” inside the guest is a band-aid. It may even create security problems by masking the fact that you have no reliable time source.

Joke #1: Time drift is like technical debt—you ignore it until it charges interest during an outage.

Interesting facts and historical context (you’ll be smarter at the end)

NTP is older than many modern OSes. The Network Time Protocol has been around since the early 1980s and is still the backbone of time sync on the internet.
Clock sync is not just “set the time.” Modern implementations discipline the clock gradually to avoid breaking time-sensitive applications.
Virtualized time has always been weird. Early VM platforms struggled with timer interrupts and scheduling, leading to guests that ran “fast” or “slow” under load.
Monotonic vs wall-clock time matters. Linux provides a monotonic clock for measuring durations; wall clock time can jump due to NTP adjustments or manual changes.
Kerberos is famously intolerant of skew. Typical default tolerances are minutes, not hours. Past that, auth fails in ways that look like “credentials broken.”
TLS relies on time for basic safety. Certificate validity windows are a simple check that stops replay and misuse. Wrong time makes secure systems look broken.
Leap seconds are a real thing. They’re rare, but they’ve caused production incidents when systems disagree about how to handle them.
Windows and Linux differ on time assumptions. Historically, dual-boot setups fought over whether the hardware clock is local time or UTC; that fight taught a generation to respect timekeeping.

How WSL2 keeps time: the moving parts

WSL2 is a lightweight VM with a real Linux kernel. It shares a lot with Hyper-V guests: virtual timers, a virtualization bus, and integration mechanisms that let the guest cooperate with the host. But “lightweight” doesn’t mean “immune to VM time issues.” It just means the failure modes are sneakier.

Three clocks you should keep distinct

Windows host wall clock: what your system tray shows; generally disciplined via Windows Time service (w32time) or domain time.
WSL2 guest wall clock: what date prints in Linux; can drift or resume stale after sleep.
Monotonic clocks: used for measuring intervals; rarely your issue in “TLS not yet valid,” but relevant if you see strange timeouts or scheduling behavior.

Why sleep/hibernate is the usual villain

When a laptop sleeps, CPU execution stops. When it wakes, the host updates its time, but the guest VM may not immediately receive a clean time sync event. If the VM is paused or its timekeeping relies on a virtual clock source that doesn’t get corrected promptly, you can resume with a clock that’s behind. The more you sleep, the more you drift. It’s not mystical; it’s state resumption.

Why “just run ntpdate” is not the right instinct

One-off time jumps can break running processes. Databases, build tools, and anything relying on timestamps can misbehave. The right approach is to enable a time service that disciplines the clock (gradual corrections), and to fix the root cause (resync on resume, ensure WSL2 integration, ensure host time is stable).

Paraphrased idea (not verbatim) from Richard Cook, reliability researcher: Failures are rarely single-point; they’re the result of normal assumptions lining up badly.

Fast diagnosis playbook

This is the “you’re on call, things are failing, and you need to know what’s wrong in five minutes” flow. Don’t overthink it.

First: confirm the skew and its direction

Check Windows time vs an external reference (or at least confirm Windows isn’t wildly off).
Check WSL2 time inside the distro.
Compute the delta. Seconds? Minutes? Hours? That scale changes the likely root cause.

Second: decide if the guest can reach a time source

Verify DNS and outbound UDP/123 reachability (or at least HTTPS access to corporate time proxies if that’s your environment).
Check whether a time daemon exists and is running (systemd-timesyncd, chrony).

Third: isolate host vs guest vs network policy

If Windows is wrong: fix Windows time first. The guest riding a broken host is not a guest problem.
If Windows is right but WSL2 is wrong: fix WSL2’s sync mechanism and resume behavior.
If both are right sometimes and wrong after sleep: implement resync on wake and verify WSL version/kernel updates.
If only corporate network breaks it: you likely have NTP blocked and need an allowed time source or a different approach.

Practical tasks: commands, outputs, decisions (12+)

These are hands-on checks you can run right now. Each task includes: command, what typical output means, and what decision you make from it.

Task 1: Check WSL2 wall clock immediately

cr0x@server:~$ date -Is
2026-02-05T14:22:09+00:00

Meaning: ISO-8601 wall clock time inside WSL2. Compare it to Windows or a known-good reference.

Decision: If it’s off by more than ~2 minutes, treat it as a real problem. If it’s off by hours, suspect sleep/hibernate resume or manual changes.

Task 2: Check time zone and whether it’s a “timezone confusion” not drift

cr0x@server:~$ timedatectl
               Local time: Thu 2026-02-05 14:22:12 UTC
           Universal time: Thu 2026-02-05 14:22:12 UTC
                 RTC time: Thu 2026-02-05 14:22:12
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: no
              NTP service: inactive
          RTC in local TZ: no

Meaning: If “Local time” matches expectations but “Time zone” is wrong, you might be seeing offset confusion. If “System clock synchronized” is no and NTP is inactive, the guest isn’t being disciplined.

Decision: If NTP is inactive, you need to enable a time service (systemd-timesyncd or chrony). If the timezone is wrong, fix that separately—don’t chase “drift” that’s actually an offset.

Task 3: Confirm systemd is actually running (WSL2 varies by config)

cr0x@server:~$ ps -p 1 -o comm=
systemd

Meaning: If PID 1 is systemd, you can use systemd services normally. If it’s something else (like init or bash), you’ll need a different approach (or enable systemd in WSL).

Decision: If systemd is not PID 1, decide whether you will enable systemd (recommended for a “real Linux” experience) or run chrony manually.

Task 4: If systemd exists, check timesync service status

cr0x@server:~$ systemctl status systemd-timesyncd --no-pager
● systemd-timesyncd.service - Network Time Synchronization
     Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled)
     Active: active (running) since Thu 2026-02-05 14:10:03 UTC; 12min ago
       Docs: man:systemd-timesyncd.service(8)
   Main PID: 319 (systemd-timesyn)
     Status: "Synchronized to time server 10.0.0.53:123 (ntp.corp)"

Meaning: “Synchronized” is what you want. If it says “No network connectivity” or “Timed out,” your network path to NTP is blocked or misconfigured.

Decision: If it’s active and synchronized, drift might be resume-related (needs wake resync) or a clock source issue. If it’s not synchronized, fix connectivity or NTP server config.

Task 5: Inspect the last sync and current offset (timesyncd)

cr0x@server:~$ timedatectl timesync-status
       Server: 10.0.0.53 (ntp.corp)
Poll interval: 32min 0s (min: 32s; max 34min 8s)
         Leap: normal
      Version: 4
      Stratum: 3
    Reference: 3B4E2A91
    Precision: 1us (-24)
Root distance: 18.525ms
       Offset: +1.842ms
        Delay: 2.913ms
       Jitter: 0
 Packet count: 109
    Frequency: -12.345ppm

Meaning: Offset in milliseconds is healthy. Root distance and stratum give you a sense of quality. Giant offsets (seconds+) mean your guest is unstable or unsynchronized.

Decision: If offset is small but you still see TLS errors, your problem may be timezone, cached DNS, or certificate chain—not time drift.

Task 6: If you’re using chrony, confirm sources and tracking

cr0x@server:~$ chronyc tracking
Reference ID    : 0A000035 (10.0.0.53)
Stratum         : 4
Ref time (UTC)  : Thu Feb 05 14:22:24 2026
System time     : 0.000001234 seconds fast of NTP time
Last offset     : -0.000000321 seconds
RMS offset      : 0.000012345 seconds
Frequency       : 15.123 ppm slow
Residual freq   : -0.001 ppm
Skew            : 0.020 ppm
Root delay      : 0.002911 seconds
Root dispersion : 0.000812 seconds
Update interval : 64.0 seconds
Leap status     : Normal

Meaning: “System time … fast/slow of NTP time” tells you your error. Healthy is near zero, stable frequency, normal leap status.

Decision: If chrony shows no reference or large offsets, you’re not actually syncing. Fix network or server configuration before blaming WSL.

Task 7: Verify name resolution and basic connectivity (because NTP can fail quietly)

cr0x@server:~$ getent hosts ntp.corp
10.0.0.53        ntp.corp

Meaning: DNS resolves the NTP name. If it doesn’t, timesync will fail even if the network is fine.

Decision: If DNS fails, fix WSL2 resolv.conf generation issues or corporate DNS access before touching time services.

Task 8: Check UDP/123 reachability indirectly (no fancy tools required)

cr0x@server:~$ sudo timeout 3 bash -c 'cat < /dev/null > /dev/udp/10.0.0.53/123' && echo ok || echo blocked
ok

Meaning: This is a crude check: it doesn’t prove NTP responses, but “blocked” suggests routing/firewall/policy issues.

Decision: If blocked, stop trying random NTP servers; you need a corporate-approved time path (or to use host-provided time sync).

Task 9: Look for suspend/resume patterns in dmesg

cr0x@server:~$ dmesg | tail -n 20
[  812.345678] systemd[1]: Started Network Time Synchronization.
[ 5432.123456] PM: suspend entry (s2idle)
[ 5432.234567] Freezing user space processes
[ 5432.345678] PM: suspend exit
[ 5432.456789] systemd-timesyncd[319]: Network configuration changed, trying to establish connection.

Meaning: If you see suspend/resume markers and then time sync re-init, you’re likely dealing with post-resume stale time.

Decision: Implement a post-resume resync hook (in WSL context: restart WSL or trigger time service restart) rather than hand-setting time.

Task 10: Confirm the guest is actually WSL2 and see version info

cr0x@server:~$ uname -a
Linux cr0x-wsl 5.15.146.1-microsoft-standard-WSL2 #1 SMP Fri Jan 10 18:20:00 UTC 2026 x86_64 GNU/Linux

Meaning: The kernel string includes Microsoft WSL2 branding. Kernel age matters; timekeeping improvements land in newer kernels.

Decision: If your kernel is old, update WSL. Don’t debug 2020-era timekeeping if you can install 2026 fixes.

Task 11: Detect “time went backwards” symptoms in logs (a classic red flag)

cr0x@server:~$ journalctl -b -p warning --no-pager | grep -i time | tail -n 5
Feb 05 14:05:01 cr0x-wsl systemd[1]: Time has been changed
Feb 05 14:05:01 cr0x-wsl systemd[1]: Detected clock change. Skipping time warp.

Meaning: Time jumps happened. Not necessarily fatal, but it explains flaky builds and “not yet valid” errors.

Decision: If time is jumping often, focus on stable discipline (chrony) and resume hooks, not manual corrections.

Task 12: Reproduce the failure in a controlled way (TLS validity check)

cr0x@server:~$ curl -Iv https://example.internal 2>&1 | sed -n '1,15p'
*   Trying 10.0.1.25:443...
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* SSL certificate problem: certificate is not yet valid
* Closing connection 0
curl: (60) SSL certificate problem: certificate is not yet valid

Meaning: “Not yet valid” often indicates the client clock is behind the certificate’s NotBefore timestamp. It can also be a weird proxy doing TLS interception with fresh certs. But time is the first suspect.

Decision: Compare date to Windows time and to the cert validity window (next task). If skew is real, fix time before chasing certificate stores.

Task 13: Inspect certificate validity dates to prove it’s time, not “mystery TLS”

cr0x@server:~$ echo | openssl s_client -connect example.internal:443 -servername example.internal 2>/dev/null | openssl x509 -noout -dates
notBefore=Feb  5 14:10:00 2026 GMT
notAfter=May  6 14:10:00 2026 GMT

Meaning: If your WSL2 time is earlier than notBefore, TLS fails exactly as shown.

Decision: Stop arguing with TLS. Fix the clock.

Task 14: Quick, low-risk “kick” — restart WSL from Windows side

cr0x@server:~$ powershell.exe -NoProfile -Command "wsl --shutdown"

Meaning: This shuts down all WSL instances. On next launch, the VM boots fresh and often picks up correct host time.

Decision: If this fixes it consistently, your root cause is resume behavior. You still want a durable fix, but now you have a safe workaround.

Task 15: Validate whether your time daemon is stepping the clock (dangerous) or slewing (preferred)

cr0x@server:~$ chronyc -n sourcestats | head
Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
10.0.0.53                   7   4   256     +0.012      0.034   +0.000   0.001

Meaning: Stable frequency and small offsets indicate slewing discipline. If you see violent corrections, you may be stepping often, which breaks apps.

Decision: Configure chrony to step only at startup and slew thereafter, unless you have a special case.

Fixes that work (and why)

There are three tiers of fixes: update/enable the plumbing, run a real time sync daemon, and handle sleep/resume. Do them in that order. Avoid “set the time in a cron job” unless your goal is to create new and exciting failure modes.

1) Keep WSL and Windows time healthy

If Windows time is wrong, everything downstream becomes theater. Fix Windows time sync first (domain joined machines should already be disciplined). On non-domain machines, make sure Windows Time service is running and not blocked by VPN policy. Then update WSL so you’re not stuck with older kernel behavior.

2) Enable systemd in WSL (if you can)

Modern WSL supports systemd when configured. Having systemd makes time sync a normal Linux problem, which is a gift. You can run systemd-timesyncd (simple) or chrony (better under weird conditions).

If you can’t or won’t enable systemd, you can still run chrony in a more manual way, but you’ll lose the clean service lifecycle hooks that make this reliable.

3) Prefer chrony when drift is chronic

systemd-timesyncd is fine for many dev laptops. But WSL2 drift patterns—especially post-suspend and under CPU contention—often benefit from chrony’s robustness and better tracking/steering behavior.

chrony also copes better with intermittent network and long gaps between sync opportunities. That’s basically the job description of a laptop VM.

4) Handle resume explicitly

If the drift appears after sleep/hibernate, you want an explicit re-sync trigger. A clean approach is to restart the time daemon (or even WSL) on resume. The “correct” hook depends on whether you manage it from Windows (Task Scheduler) or inside Linux (systemd units and timers). In a corporate fleet, Windows-driven remediation is often easier to distribute.

Joke #2: A laptop waking from sleep is basically a tiny disaster recovery exercise—just with fewer postmortems and more coffee.

chrony configuration pattern that behaves in the real world

On a corporate network, you often have an internal NTP server. Use it. Random public NTP from inside a locked-down VPN is how you spend a Thursday explaining UDP egress to security.

Example: install and configure chrony (commands differ by distro). Here’s a Debian/Ubuntu-flavored setup:

cr0x@server:~$ sudo apt-get update
Hit:1 http://archive.ubuntu.com/ubuntu jammy InRelease
Reading package lists... Done

Meaning: If this fails with “Release file is not valid yet,” your clock is behind. Fix time before continuing.

Decision: If update succeeded, proceed with installing chrony.

cr0x@server:~$ sudo apt-get install -y chrony
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  chrony
Setting up chrony (4.4-1ubuntu0.1) ...
Created symlink /etc/systemd/system/multi-user.target.wants/chrony.service → /lib/systemd/system/chrony.service.

Meaning: chrony is installed and enabled as a service.

Decision: Configure it to point at allowed servers and to step only at startup.

cr0x@server:~$ sudo bash -c 'cat >/etc/chrony/chrony.conf <<EOF
pool ntp.corp iburst
driftfile /var/lib/chrony/chrony.drift
makestep 1.0 3
rtcsync
logdir /var/log/chrony
EOF'

Meaning: makestep 1.0 3 allows stepping if offset >1s for the first 3 updates. After that, it slews. That’s a sane balance for laptop resume weirdness without breaking running workloads repeatedly.

Decision: Restart and verify tracking.

cr0x@server:~$ sudo systemctl restart chrony

cr0x@server:~$ chronyc sources -v
  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
 / .- Source state '*' = current best, '+' = combined, '-' = not combined.
| /   Reachability register (octal) - '>377' means good.
||                                                              
^* 10.0.0.53                       3   6   377    12   +0us[ +5us] +/-  20ms

Meaning: The * indicates the selected source. Reachability 377 is excellent. Offset is tiny.

Decision: If you don’t get a source and reach stays low (like 0 or 1), it’s network policy or DNS. Fix that upstream.

Resume remediation: the pragmatic approach

On affected laptops, the most consistent “fix it now” action is restarting WSL. It’s brutal, but it’s effective. For a dev workstation, this is often acceptable. For long-running processes in WSL, less so.

If you can’t afford a full WSL shutdown, restart your time service inside the distro after resume. If systemd is enabled, that’s straightforward.

cr0x@server:~$ sudo systemctl restart systemd-timesyncd

Meaning: Forces timesyncd to re-evaluate network and resync.

Decision: If timesyncd doesn’t actually sync post-resume, switch to chrony or address NTP reachability.

Common mistakes: symptoms → root cause → fix

These are the repeat offenders. If you recognize one, you can skip hours of “maybe it’s DNS” flailing.

1) Symptom: “SSL certificate is not yet valid” inside WSL2 only

Root cause: WSL2 guest time is behind after sleep/resume; Windows time is correct.
Fix: Enable chrony or timesyncd; implement post-resume resync; quick workaround is wsl --shutdown then relaunch.

2) Symptom: `apt-get update` says “Release file is not valid yet”

Root cause: Guest clock behind repository metadata timestamp.
Fix: Fix time first. Don’t disable repository date checks; that’s a security downgrade disguised as convenience.

3) Symptom: time is off by exactly your timezone offset

Root cause: Wrong timezone configuration inside the distro, not drift.
Fix: Set timezone with timedatectl set-timezone (systemd) or distro-specific tools. Keep clock in UTC; display local as needed.

4) Symptom: time correct at boot, drifts during heavy CPU load

Root cause: Guest not receiving scheduling time slices reliably; time discipline too weak; older kernel/WSL build.
Fix: Update WSL/kernel; use chrony; reduce extreme CPU starvation; avoid pinning WSL to minimal resources if it breaks timekeeping.

5) Symptom: chrony/timesyncd can’t reach any server on VPN

Root cause: Corporate network blocks UDP/123; NTP allowed only to internal servers or via special proxy.
Fix: Point your time service at approved internal NTP servers; if none exist, escalate to network/security for an approved path. Don’t tunnel to random internet NTP from corporate endpoints.

6) Symptom: “System clock synchronized: yes” but apps still complain about time

Root cause: App is using cached tokens/certs created during skew; or the issue is monotonic time vs wall clock; or it’s not time at all.
Fix: Clear/restart the affected processes after fixing time; verify with certificate dates; confirm actual wall clock with date -Is and compare.

7) Symptom: “time went backwards” warnings in journald frequently

Root cause: Repeated stepping due to aggressive config or unstable time source; or resume causes large backward jump.
Fix: Use chrony with controlled stepping (makestep only early) and slewing afterward; implement resume resync to avoid huge jumps.

Corporate mini-stories from the clock-skew trenches

Mini-story 1: The incident caused by a wrong assumption

The company had a mixed Windows/Linux dev environment, and WSL2 was the unofficial standard. Everything was fine until the team rolled out a new internal package repository with short-lived TLS certificates issued by an internal CA. The CA was properly managed. The certificates were valid. The repository was boring in the best way.

Then builds started failing. Not all builds. Not even most builds. Just a rotating set of developers, mostly laptop users, mostly the ones who closed their lids between meetings. The error was consistent: “certificate is not yet valid.” Security teams got pinged. The repository team got blamed. Someone suggested the CA clock was wrong (it wasn’t).

The wrong assumption was simple: “If Windows time is fine, WSL time must be fine.” It’s a comforting thought, like believing your backups are good because the dashboard is green. An SRE finally had a developer run date in WSL2 next to the Windows clock. The guest was seven minutes behind. That was enough to fall before the cert NotBefore boundary.

The fix wasn’t heroic. They enabled a proper time sync service in WSL2, pointed it at the internal NTP servers already used by Linux hosts, and added a lightweight “resync-on-resume” job on Windows that restarted WSL for the most affected user group. Once time was stable, TLS errors evaporated. The CA team stopped getting angry emails. The repo team stopped getting angry emails. Everyone went back to ignoring time—until the next incident, because that’s how humans work.

Mini-story 2: The optimization that backfired

A different org had a battery-life initiative. They tuned laptops for “efficiency,” which included aggressive sleep policies and CPU power saving. Someone also recommended limiting background services. In WSL2, developers started stripping services to reduce “overhead,” because of course they did. A few even disabled time sync daemons with the logic: “I’m not a server.”

A month later, intermittent auth failures showed up against an internal Kerberos-backed service. Again: not everyone, not always. The failures tended to happen in the afternoon, often after a long meeting. Developers blamed VPN. VPN blamed DNS. DNS blamed “something with Linux.” The classic corporate triangle of blame.

The real culprit was clock drift inside WSL2 after repeated suspend/resume cycles, compounded by the optimization: no time daemon to correct it. Kerberos tolerance is not a suggestion. When the drift crossed the threshold, tickets were rejected. The failures looked like “wrong password” to the application layer, which is a cruel joke performed by protocols.

The rollback was simple: re-enable time sync and relax the most aggressive sleep tuning for developers who used WSL2 heavily. Battery life dipped slightly. Productivity recovered significantly. The lesson landed the way these lessons always land: “Your laptop is not a server, but your laptop runs systems that care about time like a server.”

Mini-story 3: The boring but correct practice that saved the day

A finance-adjacent team ran a build-and-release pipeline locally in WSL2 because the corporate CI capacity was tight. It wasn’t ideal, but it was reality. The team lead had one non-negotiable rule: every dev environment must point at the same internal NTP sources as production Linux hosts, and it must be verifiable.

So they standardized on chrony in WSL2, with a config managed via a small bootstrap script. They didn’t trust “works on my machine.” They trusted “chronyc tracking shows low offset.” They also logged a simple health signal: a daily check that recorded offset and stratum into a local file. Not because it was glamorous—because it turned time into a measurable property.

One day, a corporate network change accidentally blocked UDP/123 on a subset of Wi-Fi VLANs. Developers started seeing weird issues elsewhere, but this team caught the time issue early because their daily check started reporting no reachable sources. They had evidence, not vibes.

While other groups argued about whether “the internet is down,” this team switched temporarily to an alternate approved NTP source on a different network segment and kept shipping. Later, network fixed the policy. Nobody wrote a dramatic postmortem. That’s what success looks like: boring, correct, and largely invisible.

Checklists / step-by-step plan

Checklist A: One-time stabilization (do this once per machine)

Update WSL and kernel (Windows-side) and reboot if needed.
Confirm Windows time is disciplined (domain time or reliable sync).
Inside WSL2, confirm systemd status (ps -p 1).
Enable a time sync daemon:
- If systemd is present and you want simple: enable systemd-timesyncd.
- If you see chronic drift: install and run chrony.
Point at approved NTP sources (internal NTP if corporate; otherwise stable public pools if allowed).
Verify offset (timesyncd status or chronyc tracking).

Checklist B: Post-sleep reliability (the “laptop reality” plan)

Reproduce the bug: close lid for 5–10 minutes, resume, run date -Is.
If drift occurs: decide between:
- Fast workaround: restart WSL (wsl --shutdown).
- Durable fix: implement a resume-triggered service restart (timesyncd/chrony) or WSL restart via Windows Task Scheduler.
After implementing: repeat the sleep/resume test and verify offset stays small.

Checklist C: When corporate networks get in the way

Assume UDP/123 is blocked until proven otherwise.
Find approved time servers (internal NTP, domain controllers, or sanctioned time sources).
Configure your daemon to use only those servers.
Verify reachability and tracking with chrony/timesyncd status.
If none exist: escalate. Time is a security dependency, not a personal preference.

FAQ

1) Why does WSL2 drift more than “normal Linux” on bare metal?

Because it’s a VM with a different scheduling and timer model, and laptop sleep/hibernate adds discontinuities. Bare metal usually has tighter hardware timer behavior and fewer suspend/resume edge cases in the guest.

2) Should I just run `sudo date -s` when it happens?

No. Manual time setting causes jumps that can break running processes and hides the real issue: lack of continuous discipline. Use a time daemon and fix resume behavior.

3) Is `systemd-timesyncd` enough, or do I need chrony?

timesyncd is enough when the network is stable and drift is mild. If you see repeated post-suspend skew, intermittent connectivity, or large corrections, chrony is usually the better tool.

4) My WSL2 doesn’t have systemd. Am I stuck?

You’re not stuck, but you’re playing on hard mode. You can enable systemd in WSL (recommended) or run chrony without systemd supervision. The latter works, but it’s easier to get wrong and harder to keep consistent.

5) Why does time drift break `apt` and `git` so dramatically?

apt validates repository metadata timestamps; TLS validates certificate validity windows. Both are security features. Incorrect time looks indistinguishable from an attack or corruption, so the correct behavior is to fail.

6) Can Docker inside WSL2 make this worse?

Docker itself doesn’t “cause” drift, but heavy container workloads can increase CPU contention. If the guest gets starved or your time daemon is absent/misconfigured, the skew becomes visible faster.

7) Why do my logs look out of order?

If wall clock time jumps backward or forward, log timestamps follow it. Your systems may still be functioning, but your observability becomes unreliable. Use monotonic time for durations, and keep wall clock disciplined.

8) What’s an acceptable time offset for dev work?

Keep it within a second if you can; within a few seconds is usually fine for most tasks. Once you’re in minutes, expect auth and TLS failures. In corporate environments with strict security, even small skew can be painful.

9) If Windows time is correct, why doesn’t WSL2 automatically inherit it perfectly?

Because “inherit” isn’t a constant stream; it’s mediated by virtualization integration and guest behavior. Suspend/resume, scheduling delays, and guest configuration can still produce skew.

10) Is it safe to restart WSL frequently?

It’s safe in the sense that it’s a supported operation. It’s not safe for unsaved state: it kills running processes in WSL. Treat it like restarting a VM: fine when planned, rude when done mid-workload.

Next steps you can actually do today

Do this in order. Stop when the problem stops.

Measure: run date -Is and timedatectl in WSL2. Confirm whether it’s drift or timezone.
Confirm sync service: if systemd is present, check systemctl status systemd-timesyncd (or chrony if installed).
Fix the basics: enable a daemon (timesyncd or chrony), point it at approved time sources, verify offset.
Handle sleep: if skew appears after resume, implement a deterministic action—restart time service or, if necessary, restart WSL—triggered after wake.
Validate with a failure test: repeat the TLS validity check and repository update. Don’t declare victory until the original symptom is gone.

If you take one opinionated piece of advice from this: treat time like infrastructure, even on a laptop. Especially on a laptop. Your tools are now distributed systems wearing a hoodie.