A server clock that drifts can confuse logs, authentication, certificate checks and scheduled jobs. Before manually setting the time, identify which service is responsible for synchronization and what source it trusts.
Check the current state
timedatectl status
timedatectl timesync-status
The second command is available on systems using systemd-timesyncd; other distributions may use chrony or another NTP client. Check which daemon is installed and active. Do not run multiple time services against the same clock without understanding their configuration.
Inspect the source and the network path
For chrony, use its status and source commands to see selected servers, reachability and offset. Compare the host with the intended internal time source. Check name resolution, network policy and whether UDP traffic to the configured time service is permitted.
Virtual machines may receive time corrections from the hypervisor as well as the guest service. A guest that repeatedly jumps should be investigated across both layers. Determine whether the displayed timezone is merely different from the expected local zone; a timezone mismatch is not the same as clock drift.
Correct the cause, then verify
Repair the configured source or service using the distribution's supported procedure. Avoid stepping a production clock abruptly if applications or audit records depend on monotonic event ordering; follow the service's change plan. Use UTC for system timestamps where practical and convert to local time for presentation.
After correction, observe offset and synchronization over time and check an application that was affected. Keep the time source documented: a synchronized clock is only as trustworthy as the source and network path it uses.
Related Articles