The Windows 11 clock showing the wrong time — an hour ahead, a few minutes behind, or wildly off after a restart — is fixable in under 2 minutes in most cases. But if the time keeps drifting back after you correct it, there’s an underlying cause that needs addressing. This guide covers both the quick fix and the persistent drift problem. We go deeper on the whole subject in our Complete Guide to Fixing Windows, Browser, and Software Errors.
For the quick correction: Settings → Time & language → Date & time → toggle “Set time automatically” off, then back on. This forces an immediate NTP sync with Microsoft’s time servers. The clock should correct itself within 30 seconds. If it does: you’re done, unless it drifts back — in which case there’s a connectivity or configuration issue below.
Why the clock goes wrong in the first place
Windows synchronises its clock with internet time servers (NTP — Network Time Protocol). As long as this sync works, the clock stays accurate. It goes wrong when:
- The CMOS battery on the motherboard is dying — this keeps time when the PC is off, and a dead battery means the clock resets to a default date on every boot
- The Windows Time service has stopped or is stuck
- Network connectivity is blocking port 123 (the NTP port) which time sync uses
- The time zone is set incorrectly — technically the clock is right but the displayed local time is wrong
- A dual-boot with Linux where both OSes compete over how the hardware clock is stored
Wrong time zone vs wrong time
These are different problems with different fixes. If you’ve just moved, travelled, or installed Windows, the time zone might be set incorrectly while the underlying UTC time is accurate. Result: the clock shows a time that’s consistently exactly 1, 2, or 5 hours off — never a partial-hour amount.
Settings → Time & language → Date & time → “Set time zone automatically” → On. Or manually: Time zone dropdown → pick your actual region. After changing the time zone, the displayed time adjusts immediately without resync. If the clock is off by a non-round-number amount (like 7 minutes), that’s drift, not a time zone issue.
Force a manual sync from the command line
The toggle approach above works, but command line is faster and shows you immediately whether sync succeeded or failed:
- Open Command Prompt as Administrator (Win+X → Terminal (Admin))
- Run:
w32tm /resync /force - Successful output: “The command completed successfully.”
- If you see “The computer did not resync because no time data was available”: the time server isn’t reachable
If resync fails: check which server Windows is trying to reach. Run w32tm /query /status → note the “Source” line. Default is time.windows.com. If your network is blocking that: run w32tm /config /manualpeerlist:"time.cloudflare.com,0x9" /syncfromflags:manual /update to switch to Cloudflare’s NTP server, which uses the same port (UDP 123) but a different IP.
Windows Time service — restart it
If force-resync fails or the clock keeps reverting: the Windows Time service may be stopped or stuck. Win+R → services.msc → find “Windows Time” → check the status. It should say “Running” and Startup Type should be “Automatic.” If it’s stopped or disabled:
- Right-click → Properties → Startup type → Automatic → OK
- Right-click → Start
- Then run
w32tm /resync /forceagain
The Windows Time service occasionally gets into a bad state after updates. Restarting it plus a forced sync usually resolves persistent drift.
CMOS battery — for clocks that reset on every boot
If the clock is fine while the PC is running but resets to a wrong date every time you turn it on and boot up again — especially resetting to January 1, 2000 or a similarly old default date — the CMOS battery is dead.
The CMOS battery is a small coin-cell (typically CR2032) on the motherboard that keeps a small amount of data (BIOS settings and the clock) alive when the PC is unpowered. They last 5-10 years. When they die, the BIOS loses its settings on every power-off. Replacing it costs less than £5 and takes 10 minutes on a desktop. For laptops, the location varies and it may require opening the back panel.
Test: set the clock correctly → completely power off the PC (not sleep or hibernate — full shut down) → leave it off for 30+ seconds → power back on. If the clock is wrong again immediately: CMOS battery confirmed. Buy a CR2032 from a supermarket or electronics shop → swap it → re-enter BIOS settings → done.
Our guide on Windows 11 startup and BIOS issues covers the broader CMOS-related problems that can affect boot when the battery dies, and our network troubleshooting covers cases where NTP port blocking is preventing clock sync. For NTP configuration reference and time server lists, the NTP Pool Project maintains public time servers across regional clusters that you can use as reliable NTP sources.
Dual boot Linux causing clock conflicts
This one specifically affects users who dual-boot Windows 11 and Linux. The two operating systems handle the hardware clock differently: Linux defaults to storing UTC time in the hardware clock (CMOS), while Windows defaults to storing local time. When you switch between them, each OS adjusts the hardware clock to its own assumption, and the other one reads it wrong.
Two fixes:
Fix it in Windows (easier): Open Registry Editor → HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTimeZoneInformation → create or set DWORD “RealTimeIsUniversal” to 1. This tells Windows to store UTC in the hardware clock, matching Linux’s behaviour. After a reboot, both OSes should agree on the time.
Fix it in Linux (alternative): in your Linux terminal, run timedatectl set-local-rtc 1 --adjust-system-clock. This tells Linux to use local time in the hardware clock, matching Windows. Both approaches work — pick one and stick with it.
If you’ve been dual-booting and the clock was fine, then broke after installing or updating Linux: the Linux distribution likely changed its default hardware clock handling. The Windows registry fix is usually simpler to apply.
Corporate networks blocking NTP
UDP port 123 is the NTP port. Corporate firewalls sometimes block outbound UDP 123, preventing sync with external time servers. Symptom: w32tm /resync fails with a connection error specifically at work, while the clock syncs fine at home.
Workaround: use the internal NTP server if the company has one. Most organisations run an internal time server for domain-joined machines. IT can tell you the address. Then: w32tm /config /manualpeerlist:"internal-time-server.company.com,0x9" /syncfromflags:manual /update → net stop w32tm && net start w32tm → w32tm /resync.
On domain-joined machines: the domain controller usually handles NTP sync automatically. If the clock is wrong on a work machine, it might indicate the domain controller’s NTP is misconfigured — worth flagging to IT as it can cause authentication issues across the domain.
Time drift vs wrong time
Subtle difference worth knowing: if the clock drifts by a few minutes each week rather than jumping dramatically: the time service is working but infrequently syncing, and the hardware clock is slightly inaccurate (this is normal — all clocks drift slightly without sync).
Default NTP sync interval in Windows is once per week. For machines that need higher accuracy: you can increase sync frequency. Win+R → regedit → HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeTimeProvidersNtpClient → find “SpecialPollInterval” → change from 604800 (seconds in a week) to 86400 (seconds in a day) or 3600 (hourly). The tradeoff is slightly more NTP server queries, but for any time-sensitive application this is worth it.
Apps that rely on accurate time
A wrong system clock causes cascading failures in other applications that you might not immediately connect to the clock:
- Two-factor authentication (2FA) apps: TOTP codes (Google Authenticator, Microsoft Authenticator, Authy) are time-based and fail if the system clock is off by more than 30 seconds from server time
- SSL/TLS certificate validation: HTTPS connections fail with certificate errors when the system clock is far from correct, because browsers validate certificate validity dates against the system clock
- Kerberos authentication (domain environments): fails entirely if clock is off by more than 5 minutes from the domain controller
- Email timestamps: sent emails show the wrong time, affecting sort order and “how recent is this” perception
- File modification timestamps: backups and version control systems (Git) get confused when committed files show timestamps in the past or future
The last point particularly catches developers — a wrong system clock makes Git commits show incorrect timestamps, can break CI/CD pipelines that check certificate validity, and causes build tools to incorrectly determine which files have changed.
When to trust the BIOS clock vs Windows clock
A useful diagnostic: enter BIOS/UEFI at boot (press F2 or Delete during POST) → look at the date and time displayed there. If the BIOS shows the correct time but Windows shows wrong: the issue is Windows-side (time service, sync server, settings). If the BIOS also shows wrong time: it’s hardware (CMOS battery) or the BIOS timezone setting itself.
Some BIOS implementations show UTC time by default while Windows shows local time — so they can appear to disagree by your UTC offset without either being “wrong.” Keep this in mind when comparing; add or subtract your UTC offset from what BIOS shows to get the expected local time.
| Clock symptom | Likely cause | Fix |
| Consistently X hours off | Wrong time zone | Settings → Time zone → correct region |
| Wrong by a few minutes, drifts | Infrequent NTP sync | Force resync; increase poll frequency |
| Resets completely on every boot | Dead CMOS battery | Replace CR2032 on motherboard |
| Resync command fails | Service stopped or port blocked | Restart Windows Time service; try alternate NTP server |
| Clock drifts only at work | Corporate firewall blocking UDP 123 | Use internal NTP server |
| Clock changes when switching OS | Linux/Windows UTC conflict | Set RealTimeIsUniversal in registry |
The most common fix by far is just the toggle-off/on or the w32tm /resync /force command — 95% of “wrong clock” reports are just a failed sync that resolves instantly with a manual nudge. Persistent drift, boot-time resets, and cross-OS conflicts each have clear signatures that point to their specific causes above.
Checking the Windows Time event log
For persistent sync failures, the event log shows exactly what went wrong. Win+X → Event Viewer → Windows Logs → System → look for events from “W32Time” source. Error events show the specific failure: DNS resolution failure (wrong NTP server name), network unreachable, service crash, or peer rejection.
This is the quickest way to understand why w32tm /resync keeps failing without physically trying different fixes. The error code in the event tells you the specific problem and narrows the fix significantly.
Multiple monitors and taskbar clocks
On multi-monitor setups, the clock shown on each display’s taskbar is the same Windows clock — there’s no separate time per monitor. If it looks like monitors show different times: you’re looking at a visual glitch where the taskbar on a secondary display hasn’t refreshed. Click on the taskbar clock on that monitor to refresh it, or move the mouse over it. This is a display rendering issue, not a clock accuracy issue.
When the clock is right but 12/24 hour format is wrong
The actual time is correct, but it’s displayed in 12-hour format when you want 24-hour (or vice versa). This is a separate regional setting from time sync.
Settings → Time & language → Language & region → Regional format → “Change formats” → Short time → change between h:mm tt (12-hour) and H:mm (24-hour). Also “Long time” for the same. These format strings match the Windows locale format specification — “H” for 24-hour, “h” for 12-hour. Applying the change takes effect immediately on the taskbar clock.
For AM/PM indicator to disappear entirely: set Short time to “H:mm” with no “tt” at the end. The clock area in the taskbar is compact and showing “AM” or “PM” alongside the time takes space some users prefer to recover by switching formats.
Travelling users and time zone changes
When you travel across time zones with a laptop, Windows can automatically adjust the clock if “Set time zone automatically” is enabled. It uses your network location and IP geolocation to determine the time zone. This usually works but occasionally picks wrong time zones in border regions, on VPNs, or in areas with unusual time zone shapes (like the US which has multiple time zones across a single state in some cases).
If auto-detection is getting the wrong zone: turn off “Set time zone automatically” and set it manually for wherever you are. Re-enable when you return home or when you want Windows to start auto-detecting again. Manual zone is more reliable if you’re frequently in the same known location and auto-detection keeps guessing incorrectly.
For frequent travellers: there’s no built-in “secondary clock” for a home time zone on the taskbar in Windows 11’s default view, but you can add additional clocks via Settings → Time & language → Date & time → “Additional clocks” → enable and set the additional time zone. They appear when you hover over the taskbar clock, showing multiple zones simultaneously. Our guide on Windows 11 Date and Time Wrong covers an adjacent issue.
