Windows 11 Clock Wrong or Time Keeps Changing: Troubleshooting

A Windows 11 clock that is wrong by exactly one or several hours is a different symptom from a clock that slowly drifts, refuses to synchronize, or resets after every shutdown. Check the displayed date, time, and time zone before changing services or firmware settings. This first split prevents a simple zone error from turning into an unnecessary Windows repair exercise.

Also note when the error appears. If Windows shows the correct time after synchronization but becomes wrong only after a full power-off, compare the firmware clock before Windows starts. If the firmware clock remains correct while Windows alone is wrong, keep the investigation in Windows. If the firmware clock itself repeatedly loses its date or time, Windows Time is not the only layer involved and the PC or motherboard vendor becomes the appropriate hardware-specific source.

Open Settings > Time & language > Date & time. Microsoft documents separate controls for setting time automatically, setting the time zone automatically, and daylight-saving behavior. A correct UTC-based clock paired with the wrong time zone can display the wrong local hour even though network time synchronization itself is healthy.

For a normal personal PC, leave Set time automatically enabled unless you are deliberately testing manual time. If automatic time-zone detection is wrong or unavailable, select the correct time zone manually and keep the daylight-saving option appropriate for that zone. After changing the zone, re-check the displayed time before touching the Windows Time service.

Windows 11 uses the Windows Time service, also called W32Time, for network clock synchronization. Microsoft documents that non-domain computers are configured by default to synchronize with time.windows.com, while domain-joined computers normally follow the Active Directory domain time hierarchy. That distinction matters because a work PC can be behaving exactly as its organization configured it to behave.

After confirming the zone, use the Sync now control in Settings > Time & language > Date & time. If synchronization repeatedly fails, an elevated Command Prompt can provide diagnostic state without changing configuration: `w32tm /query /status` reports synchronization status and `w32tm /query /source` shows the current time source. Record the output before making changes.

Windows Time obtains samples from a configured time source over the network and uses time-synchronization algorithms to discipline the local clock. Microsoft notes that network conditions, hardware-clock accuracy, and available resources can affect synchronization. A failed Sync now attempt therefore does not by itself identify a motherboard fault.

Confirm that the PC has normal network access and that Windows Time reports a source. On a managed network, firewall policy, domain configuration, VPN state, or the organization's time hierarchy may be relevant. Avoid copying random NTP server or registry commands from generic fix lists: changing the source can hide the actual domain or policy problem and is especially inappropriate on managed PCs.

Microsoft documents a predetermined time hierarchy for Active Directory Domain Services. Domain members normally synchronize through that hierarchy rather than independently choosing a public Internet source. Correct time is also important to Kerberos authentication and other network validation, so an incorrect domain clock can have consequences beyond the taskbar display.

If `w32tm /query /source` on a managed PC points to a domain source, preserve that evidence and contact the administrator when it is wrong or unreachable. Reconfiguring the client to use a public NTP server can put it out of step with the domain and is not a sound troubleshooting shortcut.

A useful boundary test is to restart into the PC firmware setup and inspect its date and time before Windows loads. If firmware time is stable but Windows later displays the wrong local time, return to Windows settings, synchronization, dual-boot configuration, or management policy. If the firmware date/time itself repeatedly resets after power loss, the symptom exists below Windows.

Do not diagnose a failed CMOS/RTC battery from the Windows clock alone. Firmware implementations and hardware differ, and a reset firmware clock deserves model-specific documentation or vendor diagnostics before replacing parts. The important diagnostic result is simply whether the error already exists before Windows starts.

A virtual machine can receive time from both its guest operating system and virtualization platform, depending on the product and configuration. Microsoft specifically documents additional considerations for virtualized Windows systems. If only a VM has the wrong time, compare the host clock, guest time zone, and hypervisor time-integration settings before changing the physical PC.

Dual-boot systems can also make the symptom appear only after switching operating systems because more than one OS may interact with the hardware clock. That is a different diagnostic path from a standalone Windows PC that cannot reach its configured time source. Record whether the error appears specifically after booting another OS; do not apply registry changes without understanding the other operating system's clock convention and your exact configuration.

If the problem persists, capture the selected time zone, whether Set time automatically is enabled, the output of `w32tm /query /status` and `/source`, whether the PC is domain joined, and whether the firmware clock is correct before Windows starts. Those observations identify which layer owns the failure far better than repeatedly toggling services.

For a personal PC with a stable firmware clock but persistent Windows synchronization failure, use Microsoft support or the PC vendor with that evidence. For a managed PC, use the organization's administrator. For a firmware clock that repeatedly loses state, use the motherboard or system vendor's hardware documentation. Avoid destructive Windows resets or undocumented registry edits as first-line clock troubleshooting.