Windows 11 Clock Wrong or Not Syncing: Time Zone, Windows Time, NTP, and CMOS

A wrong Windows clock can mean several different things: the displayed hour is offset by a whole number of hours, the time is only seconds or minutes wrong, synchronization fails, the clock gradually drifts, or the date and time reset after shutdown. Record which pattern you have before changing services or firmware. A whole-hour error often points toward the time-zone layer, while a clock that resets across power cycles deserves a different branch from a clock that is correct after every successful network synchronization.

Also establish whether the PC is a normal standalone/home machine or is joined to an Active Directory domain. Microsoft documents different time-source behavior for those cases: non-domain Windows computers normally use an Internet time source, while domain members normally synchronize through the AD DS domain hierarchy. Do not force a public NTP server onto an organization-managed PC unless its administrator intends that configuration.

Open Settings > Time & language > Date & time. Microsoft documents Set time automatically as the normal automatic-clock control and exposes the time-zone setting separately. Confirm both the clock mode and the actual time zone. If the displayed time is wrong by exactly one or several hours while minutes are correct, fix the time-zone configuration before treating the Windows Time service as broken.

A manual time change can temporarily make the taskbar look correct without fixing synchronization. Use it only as a bounded test or when automatic time is intentionally disabled. After changing a setting, verify whether the clock remains correct through a restart and after the next synchronization opportunity.

Microsoft identifies w32tm as the preferred command-line tool for configuring, monitoring, and troubleshooting the Windows Time service. From an elevated Command Prompt, `w32tm /query /status` can show synchronization status and `w32tm /query /source` identifies the current source; `w32tm /query /configuration` exposes the effective configuration. Record those results before changing peers or service settings.

If the source is not what you expected, first ask why. A domain member normally follows the domain hierarchy, while a standalone PC can use a manually configured source such as the default Internet-time configuration. Group Policy can also determine effective settings. Changing registry values or peer lists without understanding that ownership can be overwritten later or can break organization time policy.

When Windows cannot synchronize, establish whether it has a usable time source and whether that source is reachable. The Windows Time service uses NTP for network time synchronization, and Microsoft documents w32tm as the supported diagnostic surface. A failed `w32tm /resync` is evidence that synchronization did not complete; it does not by itself identify the motherboard battery, network, server, or Windows service as the root cause.

On a home PC, confirm ordinary network access and inspect the configured source before resetting the service. On a managed network, contact the administrator when the machine is expected to use domain time. Do not disable firewall or security controls broadly just to make NTP work; determine whether the intended time source and required network path are actually permitted.

Microsoft documents a hierarchy for Active Directory time synchronization: domain clients normally use an authenticating domain controller, domain controllers follow the hierarchy toward the PDC emulator, and the forest-root authority is configured to obtain reliable upstream time. That design also matters for authentication; large time differences can interfere with Kerberos and other domain operations.

If a work or school PC is domain joined, do not copy a consumer recipe that permanently points it at an arbitrary public NTP server. Capture `w32tm` status, source, and configuration, then escalate through the organization that owns the domain policy. The correct fix may be upstream from the client.

If the date or time repeatedly becomes wrong after a full shutdown or loss of power, compare the clock shown in UEFI/BIOS with Windows. A firmware clock that is also losing its setting shifts the investigation below Windows toward the real-time clock, motherboard power state, firmware, or hardware service path. A correct firmware clock with a wrong Windows clock keeps the Windows configuration and synchronization branches in play.

Do not declare the CMOS/RTC battery dead from one incorrect Windows timestamp. Microsoft also documents cases where Windows can revert to stale time information under specific network conditions, so the reset pattern and firmware comparison matter. If the firmware repeatedly loses time or other retained settings when external power is removed, follow the motherboard or system manufacturer's service guidance for the exact device.

Windows Time can be configured for high-accuracy environments, but Microsoft treats that as a specific configuration problem with network, topology, hardware, and service requirements. An ordinary gaming or home PC does not need custom registry tuning simply because two clocks differ by a tiny amount. First determine whether the difference is operationally meaningful and whether Windows reports itself synchronized.

If you actually need precise time for measurement, distributed systems, logging, finance, laboratory work, or another controlled workload, use Microsoft's high-accuracy Windows Time guidance and design the time path intentionally. Do not turn a troubleshooting article into an unsupported promise that one public NTP server or polling tweak will hold a universal precision target.

Classify the error pattern; verify automatic time and the correct time zone; determine whether the PC is standalone or domain joined; inspect `w32tm` status, source, and configuration; test synchronization only after identifying the intended source; and compare the firmware clock if time resets across shutdowns. Change one layer at a time and retest the same condition.

Escalate with the Windows version, whether the PC is domain joined, the exact `w32tm` source/status, the size and direction of the time error, whether the firmware clock is correct, and when the problem returns. Avoid random registry edits, permanent service-disable recipes, arbitrary public NTP substitutions on managed PCs, and premature motherboard-battery replacement.