Windows 11 showing the wrong date or time — events appearing in the wrong time slot, file timestamps being off, or the system clock drifting — is usually a quick fix. The wrong time affects more than you’d expect: authentication tokens, file sync, and security certificates all depend on accurate system time. For the bigger picture, our Complete Guide to Fixing Windows, Browser, and Software Errors pulls everything together.
Fast fix for most cases: Settings → System → Date and time → toggle “Set time automatically” off → on → click “Sync now.” This forces an immediate sync with Microsoft’s time server. For most people, this resolves the issue immediately.
If the clock is wrong again within hours or days: there’s an underlying cause (CMOS battery, NTP access blocked, or time zone issue) that needs addressing.
Time zone is the most common culprit
The system clock can be perfectly accurate while showing the “wrong” time if the time zone is set incorrectly. Settings → System → Date and time → confirm “Time zone” shows your actual location. A VPN that connects through servers in another region can sometimes cause Windows to suggest a wrong time zone; Windows occasionally changes the time zone automatically based on location data.
If “Set time zone automatically” is enabled and showing the wrong zone: toggle it off → manually select the correct time zone. Windows’ automatic time zone detection uses location services and can be inaccurate, particularly in border areas between time zones or when using a VPN.
Syncing with the time server
When automatic time is enabled but the clock is still wrong: the time sync may have failed silently. To force a sync and verify it works:
- Win+R → type
services.msc→ find “Windows Time” → confirm it’s Running - Open Command Prompt (Administrator) and run:
w32tm /resync /force
w32tm /query /status
The /resync command forces an immediate sync. The /query /status command shows the last sync time and source, and whether the sync succeeded. If it shows errors: the time server is unreachable or the service has an issue.
Changing the time server
Windows defaults to time.windows.com. If that server is slow or unreachable from your location: the clock drifts. Switching to a different NTP server often resolves intermittent time sync failures.
Settings → Date and time → “Additional clocks” → Internet Time → Change settings → enter a different server:
- pool.ntp.org — a global pool with automatic geographic routing
- time.cloudflare.com — Cloudflare’s time service with good uptime
- time.google.com — Google’s time service
Click “Update now” → confirm “The clock was successfully synchronised.” If it fails with any server: a firewall is likely blocking NTP (UDP port 123).
CMOS battery — the cause of persistent drift
If the clock resets to a wrong time every time the computer starts (not just drifts slowly): the CMOS battery is the problem. This small coin cell battery on the motherboard maintains BIOS settings and the hardware clock when the machine is unpowered. When it fails: the BIOS clock resets to a default date (often January 1, 2009 or similar) every boot.
Signs of a dead CMOS battery:
- Clock shows a very old date (2000s or January 1 of any year) after booting
- BIOS settings reset after power loss
- The machine shows a CMOS checksum error at startup
CMOS batteries are CR2032 coin cells, universally available for £1-3. Replacing them takes 5 minutes and is straightforward on most desktops and most laptops (though some laptops have the battery in harder-to-reach locations).
Corporate environments and NTP
Domain-joined Windows machines synchronise time from the domain controller (not from internet time servers). If the domain controller’s time is wrong: all machines in the domain show the wrong time. Individual machines can’t override this sync when domain-joined — IT needs to fix the domain controller’s time synchronisation.
On a domain machine: w32tm /query /source in Command Prompt shows the current time source. If it shows the domain controller name: time sync is working as designed. If the time is still wrong: report the domain controller name to IT — they can investigate the DC’s own time sync.
Firewall blocking NTP
Corporate firewalls often block outbound UDP port 123 (NTP) to control which time servers machines can use. If Windows Time sync fails with “The service has not been started” or similar errors after forced resync attempts: NTP may be blocked. Check with IT, or if NTP is blocked but you need time accuracy: HTTPS-based time sources (time.cloudflare.com supports HTTPS time queries) can work through port 443 instead.
Dual-booting Windows and Linux
When Windows and Linux are both installed on the same machine: they interpret the hardware clock differently. Linux stores UTC time in the hardware clock and converts to local time on display. Windows (historically) stores local time in the hardware clock. Each time you boot from one to the other, the other misinterprets the stored time value and shows the wrong time.
The clean fix: configure Linux to use local time (matching Windows’ approach): timedatectl set-local-rtc 1 in Linux. Or: configure Windows to use UTC storage through a registry change. Either approach makes both systems agree on the hardware clock format.
Our guide on Windows 11 startup issues covers the BIOS battery and settings reset that accompanies CMOS battery failure. For the network connectivity issues that prevent NTP sync, our network troubleshooting guide covers the connectivity diagnostics including firewall rule checking. Microsoft’s time synchronisation documentation covers the W32tm command-line tool in detail, including how to configure Windows machines as NTP servers for local network time distribution.
Windows Time service configuration
The Windows Time service has configurable parameters that affect how aggressively it corrects clock drift. By default, Windows Time only syncs once every several hours and applies corrections gradually. For machines that drift badly or need accurate time for authentication:
sc config w32time start= auto
net start w32time
w32tm /config /manualpeerlist:"pool.ntp.org" /syncfromflags:manual /reliable:YES /update
w32tm /resync
Administrator Command Prompt. This configures Windows Time to use pool.ntp.org, marks the time source as reliable, and forces an immediate sync. The service stays configured this way through restarts.
Drift rate and accuracy requirements
Most Windows machines drift 1-5 seconds per day — effectively zero impact for normal use. Environments that need higher accuracy:
- Financial systems: trading platforms and payment systems may require sub-second accuracy
- Kerberos authentication: Active Directory Kerberos authentication fails if the clock is more than 5 minutes off from the domain controller. This causes “The security clock skew is too great” errors during login or network authentication
- TOTP two-factor authentication: Google Authenticator and similar apps use time-based codes. If the clock is more than 30 seconds off: 2FA codes will fail
- TLS certificate validation: certificates have validity periods. An incorrect date outside the certificate’s valid range causes HTTPS connections to fail
Clock wrong after Windows update
Windows feature updates occasionally change time zone data. DST (Daylight Saving Time) rule changes that Microsoft incorporates via updates can shift the displayed time if the update was applied near a DST transition. After a major Windows update: verify both the time zone setting and whether DST is being applied correctly in Settings → Date and time.
Hibernate and wrong time
Windows does not sync the clock after waking from hibernation by default. If the machine hibernated for several days: the displayed time may be hours off because the hardware clock drifted during hibernation without a sync. A manual sync (w32tm /resync or click “Sync now” in Settings) after waking from extended hibernation corrects this quickly.
AM/PM and 24-hour format
Sometimes the “wrong time” is actually the right time in a different format. If the clock shows 3:00 when it should be 15:00: the time is correct but displayed in 12-hour format where the context expected 24-hour format. Settings → Time and language → Language and region → Regional format → Additional date, time and region settings → Change date, time, or number formats → Time tab → change between 12-hour (h:mm tt) and 24-hour (H:mm) formats.
Virtualised environments
Windows running inside a virtual machine (Hyper-V, VMware, VirtualBox) inherits time from the host machine by default through VM integration tools. When the VM’s time integration is broken or disabled: the VM clock drifts independently. VMware guests: VMware Tools controls time sync. Hyper-V guests: Integration Services handles it. If the VM clock is wrong: check that the VM’s time synchronisation integration component is enabled in the VM settings and that the tools are current.
Group Policy time settings
In enterprise environments, Group Policy can configure Windows Time service settings including the NTP server, sync interval, and maximum allowable time difference. Local time settings in Windows Settings may appear to change but get overwritten by Group Policy at the next refresh cycle.
To check: run gpresult /r in Command Prompt and look for any Computer Configuration policies related to “Windows Time Service” or “NTP.” If Group Policy is controlling time: only IT can change the configured time server or sync frequency. Users making local changes will have them overridden by the next Group Policy refresh (typically every 90 minutes).
Impact of wrong time on Windows features
A significantly wrong system clock has cascading effects:
- HTTPS websites show certificate errors (the certificate appears invalid because the date is outside its valid range)
- Email timestamps show wrong send/receive times
- File modification timestamps are wrong, which can break version control systems and backup incremental logic
- Windows Hello and Microsoft account login may fail (authentication tokens are time-sensitive)
- Event Viewer logs have wrong timestamps, making troubleshooting historical events harder
Getting the system clock right isn’t just about showing the correct time on screen — it’s foundation infrastructure for everything else on the machine.
Automatic time zone detection
Settings → Date and time → “Set time zone automatically” uses Windows Location Services to determine the time zone. If Location Services is disabled (Settings → Privacy and security → Location → Off): automatic time zone detection can’t work and defaults to the last manually set time zone.
For travel use: enable Location Services temporarily when moving to a new time zone → let Windows detect and set the new zone → then disable again if privacy is preferred. Or manage time zone manually when traveling.
| Symptom | Cause | Fix |
| Time wrong, corrects after “Sync now” | NTP sync failed silently | Manual sync; change time server |
| Time resets to old date on every boot | Dead CMOS battery | Replace CR2032 battery |
| Time zone wrong, time correct | Wrong time zone set | Set correct time zone manually |
| Certificate errors on HTTPS sites | Clock significantly wrong | Sync now; fix underlying drift cause |
| Domain machine, time always drifts | Domain controller time wrong | Report to IT; DC controls the sync |
| VM clock drifts | VM time integration disabled | Enable time sync in VM tools settings |
The Windows clock is one of those things that silently affects many other features when it’s wrong. Fixing it is usually a 60-second task (toggle auto-time off and on, click sync). The CMOS battery failure and domain controller scenarios are the cases that require more investigation, but they’re also the cases where the symptom (clock resets completely on every boot, or clock is wrong consistently on a managed machine) clearly distinguishes them from the simple sync failure.
One pattern that’s easy to miss: 2FA apps showing “incorrect code” when the clock is off by more than 30 seconds. This is often reported as “my authenticator app stopped working” when the actual issue is that the Windows clock drifted. Syncing the system time immediately fixes 2FA authentication without any changes to the 2FA setup itself. If 2FA codes stop working: check the system clock as a first step before assuming the 2FA configuration is broken.
Time sync event logging
Windows Time service logs events in Event Viewer → Windows Logs → System → filter for Source “W32Time.” These events show every sync attempt: whether it succeeded, what server was used, and how much the clock was adjusted. If the clock keeps drifting despite apparent successful syncs: the event log shows whether syncs are actually completing or failing silently. Event ID 35 indicates successful sync; Event ID 29 indicates sync failure. Reviewing these events tells you exactly how often syncs are occurring and whether they’re working.
For machines that drift significantly even with successful regular syncs: investigating hardware temperature may reveal the cause. Temperature extremes (very hot or cold operating environments) affect oscillator accuracy in both the CMOS clock and the NTP client’s drift compensation. This is uncommon in normal office environments but relevant for industrial or server room deployments where temperature fluctuations are greater. If drift is consistently in one direction (always running fast or always running slow): it’s often a thermal effect on the real-time clock crystal, which degradation only NTP sync can compensate for. Our guide on Windows 11 Clock Wrong covers an adjacent issue.
