Conclusion: Record the current clock difference before changing settings
In Settings, check "Set time automatically" and the time zone, then read w32tm /query /status and /source in an elevated Command Prompt. Resynchronize only after checking status and policy, then measure clock drift again at the end.
| order | What to Check | Points of judgment |
|---|---|---|
| 1 | Current clock difference | Save the offset and round-trip time before changing settings |
| 2 | Windows settings | Whether automatic time setting and the time zone are as intended |
| 3 | W32Time | Service status, last synchronization, and time source |
| 4 | network | Name resolution for the sync destination and the UDP 123 policy |
| 5 | Device management | Domain hierarchy, Group Policy, and administrator instructions |
Consider clock deviation, TimeZone, and communication delay separately.
Even if the displayed time looks different, it does not necessarily mean that the clock itself is incorrect. If the same moment is expressed in UTC and JST (UTC+9), it will look 9 hours different. On the other hand, if there is a difference of several seconds or minutes even after aligning the clocks to the same TimeZone, there is a possibility that the clocks are out of sync. Communication time is also included in measurements that obtain the reference time from the browser.
| types | example | Check first |
|---|---|---|
| Clock Skew / Offset | At the same moment, the reference clock reads 12:00:00 and the device clock reads 12:00:08 | Check the clock synchronization status, time source, and OS services |
| TimeZone differences | UTC 03:00 and JST 12:00 are the same moment | Check your regional settings and how to convert to UTC |
| Communication delay | It takes time from time API request to response | Record the round trip time and use the measured value as a guide. |
| Differences in display format | Seconds/milliseconds, Unix Time, ISO 8601, local notation is different | Compare using the same standards and units |
We don't immediately judge things like, "The clock is off by 9 hours because it's 9 hours off," or "It's abnormal because it's off by a few ms." Compare standards, TimeZone, units, and communication conditions.
Isolate the main cause candidates in order of priority
- Automatic time setting is disabled or synchronization has failed
- The TimeZone does not match the region
- Windows Time Service is stopped or cannot select a time source
- NTP communication is blocked by DNS, a Firewall, VPN, or similar factors.
- A domain hierarchy or Group Policy is overriding manual settings
Microsoft Learn describes W32Time as the Windows time synchronization service, and domain-joined PCs use the AD DS time hierarchy by default. It is important not to handle personal PCs and domain-joined PCs with the same configuration steps.
Do not arbitrarily set your device clock forward in time to avoid authentication errors. Synchronizing to the correct TimeZone and reliable time source is fundamental.
Check the status of OS/time synchronization service
First read the state and time source and leave the unmodified result. Management policies may take priority on organization management terminals, domain-joined PCs, and cloud VMs, so we do not change the time source or service settings without permission.
| Item | Confirmation details | Points to note |
|---|---|---|
| 2 | Windows settings | Whether automatic time setting and the time zone are as intended |
| 3 | W32Time | Service status, last synchronization, and time source |
| 4 | network | Name resolution for the sync destination and the UDP 123 policy |
| 5 | Device management | Domain hierarchy, Group Policy, and administrator instructions |
w32tm /query /status
w32tm /query /source
w32tm /query /configurationEven if the command name is the same, the output and setting method will differ depending on the OS, distribution, product version, and permissions. Compare the examples in the article with official documentation.
Points I would like to confirm in particular regarding this issue
- Check the Last Successful Sync Time and source
- Check whether source is the intended NTP server or domain hierarchy.
- When resynchronization fails, check event logs and the network path
- On managed devices, prioritize management policy over manual peer settings
Even if a clock difference is found, this alone does not confirm the cause of the problem. Gather the error time, time source, TimeZone, and reproduction steps into the same record and compare it with other possible causes.
What the clock drift checker can and cannot tell you
| Item | implementation | constraints |
|---|---|---|
| Device time | Obtained from the system clock of the device running the browser | Do not measure the clock on the server or another device. |
| Reference time | UTC time returned by /api/time on the same site. Use HTTP Date if you can't read JSON | It is not a function that directly queries the NTP server. |
| delay compensation | Simple correction that adds half of the round trip time from request to response to the reference time | Outbound and return trips are not necessarily the same, and high accuracy is not guaranteed. |
| Number of measurements | Get time API once per confirmation button | Do not use average value, median value, or continuous monitoring. |
| Display | Clock offset, device time, browser TimeZone, estimated source TimeZone, round-trip time | The clock difference is displayed in ms for less than 1 second, and in seconds for more than 1 second. |
| Local display | Display device time and TimeZone without communication | The accuracy of the clock cannot be determined because there is no standard time to compare it to. |
The calculation is "device time when response is received - (API reference time + round trip time ÷ 2)". The results are sensitive to network conditions, including the simplification that the outbound and inbound delays are approximately the same. It measures once each time you press the button, and does not display the average or median value of multiple measurements.
API errors, timeouts, offline, JavaScript disabled, etc. are "conditions that cannot be measured." It does not determine that the clock is off. The correctness of the clock cannot be determined based on the local display alone.
Correct the settings and check again under the same conditions
- Correct automatic time settings and TimeZone in Windows settings
- Correct W32Time status and time source through an administrator or official procedure
- Check DNS, firewall, VPN, and UDP 123 permission scope
- Recheck the last synchronization with w32tm, then measure clock drift again in the browser
Use the same device, network connection, and browser before and after the change, and record both clock offset and round-trip time. If the results are unstable, repeat several separate measurements without switching networks and compare them. The tool does not calculate an average.
The display classification of within 2 seconds and within 30 seconds on the tool screen is a guideline on the UI to make the results easier to read. This is not a common system safety standard. Check the requirements for each application, such as authentication, distributed processing, finance, measurement, audio/video, etc.
Check the official information for specifications and commands
Time synchronization behavior varies depending on the OS, services, libraries, and management policies. When changing settings, check the primary documentation that corresponds to the version you are using.
| source of information | What we confirmed in this article |
|---|---|
| Microsoft Learn「Windows Time Service」「Windows Time service tools and settings」 | W32Time, domain hierarchy, current w32tm commands, and explanation of UDP 123 |
| RFC 5905「Network Time Protocol Version 4」 | Basic specifications for NTPv4 time exchange, offset and delay |
| Implementation of the DevelopTools clock drift checker | /api/time, HTTP Date fallback, simple correction by half round trip time |
Summary
Time-related problems can be easily isolated by separating clock deviation, TimeZone, display format, and communication delay, recording the current value, and then checking the OS and synchronization service. After changing settings, measure again under the same conditions and check against the tolerance of the target system.
- Record the current clock difference and round-trip time first
- Check automatic time setting, time zone, W32Time, and synchronization source in order
- On domain-joined PCs, prioritize the organization's time hierarchy and management policies
Example: The time is two minutes ahead even though automatic settings are enabled
Browser measurement confirms that the device clock is about two minutes ahead of the reference and that round-trip time is small. Because the Asia/Tokyo time zone is correct, investigate synchronization status rather than display conversion.
When checking w32tm status and source shows that the last synchronization is old, check W32Time and network policy before resynchronizing.
- Record clock difference and round-trip time.
- Check automatic time and TimeZone in Windows Settings.
- Check status, source, and configuration with w32tm.
- Correct synchronization through the management procedure, then measure again on the same network.
On managed PCs, do not change the time source to public NTP on your own; share the results with an administrator.
Frequently asked questions
- Can w32tm be run by a standard user?
- It depends on the query and environment, but Microsoft's instructions may direct you to open Command Prompt as an administrator. On managed devices, check permissions and operational rules.
- Will pressing the sync button always fix it?
- No. If the cause is the time source, service, network, domain policy, or similar, resyncing alone may not fix it.
Try It in Your Browser
Your input is processed entirely in your browser. Keep the original data, review the output, and only then save or share it.
Open the clock drift checker