A computer clock can be corrected in two different-looking ways. It may jump to a new time, or it may temporarily run slightly faster or slower until the error is reduced. Both can be part of time synchronisation, but they affect the sequence of timestamps differently.
A step changes the reading immediately
Stepping adjusts the clock directly. Slewing changes its rate for a period. The chrony configuration manual describes these behaviours and the conditions under which its time service can make a step. Other operating systems and services have their own policies.
A large correction at startup may be handled differently from a small adjustment while applications are running. Therefore, “automatic time is enabled” does not tell you exactly how every discrepancy will be resolved.
Read logs with the clock history in mind
Imagine a device that reconnects after a long period offline. If its wall clock is corrected backwards, two events written in order might appear to have timestamps that move backwards too. That possibility should prompt a check of synchronisation records before concluding that the application reordered the events.
When documenting a problem, record the time zone, the device’s clock settings, the time source if available and whether the issue followed startup or reconnection. Compare events using their original records rather than manually editing timestamps to make them look tidy.
For software timing, elapsed duration and calendar time are separate needs. Developers often use a monotonic clock for intervals so ordinary wall-clock corrections do not distort a stopwatch-like measurement.
Do not change production time-service settings casually to eliminate an unfamiliar log entry. Applications and authentication systems can depend on correct time, and a correction policy belongs in the system’s operating plan.
A clock reading and the rate at which that clock advances are both adjustable. Knowing which changed can explain a puzzling timestamp without assuming the whole record is unreliable.