Monotonic clock: choosing a reference for elapsed duration

Subtracting two calendar timestamps can produce a duration that differs from the interval between the events. If the calendar clock is corrected between readings, the subtraction includes both the elapsed interval and the correction. A backward step can even make the result negative.

A monotonic clock offers a different contract: readings do not go backward within the domain and lifecycle for which that property is specified. It is useful for interval reasoning, but monotonicity alone says neither how accurately it tracks physical seconds nor whether it includes time spent suspended.

The reference should be selected according to the question. Dating an event, timing a timeout, and measuring active-system duration can need different properties even when every clock reports values in seconds.

Wall clock adjustment changes the subtraction

Use a hypothetical calendar clock that reads 12:00:00 at the start of an event. Five physical seconds later, its ordinary progression would produce 12:00:05. If a correction has moved it backward by ten seconds during that interval, its final reading is 11:59:55.

Subtracting the first label from the second gives minus five seconds. The event did not run backward or have negative duration. The calendar-clock difference contains five seconds of progression minus a ten-second adjustment.

If instead the clock receives a forward correction of thirty seconds, the final label becomes 12:00:35. The same physical five-second interval then yields a calendar difference of thirty-five seconds. These are stipulated arithmetic examples, not observations of a particular operating system.

The guide linked through wall clock adjustment provides supporting correction context: a two-way network timing exchange can confuse unequal path delays with a clock offset. It does not define an operating system's interval-clock contract. Its relevance is that a calendar correction is an estimate-dependent change, not direct evidence that the event duration changed.

A calendar clock can also correct its rate gradually instead of stepping its value. In that case there may be no backward jump, while elapsed differences still include the rate adjustment. Observing nondecreasing calendar labels over one record does not establish a general interval-measurement guarantee.

Elapsed time measurement needs its own contract

For two readings m1 and m2 from the same valid interval domain, the difference m2 minus m1 represents the interval according to that clock's contract. The relevant documentation must define how the clock advances, which lifecycle preserves its origin, and what conditions change its rate or continuity.

A nondecreasing clock may return the same value for two nearby observations because its resolution is finite. That is compatible with monotonicity. The measured difference is then zero even though a small physical interval has passed.

The TCP retransmission-timer guide provides a concrete elapsed time measurement example: an identifiable transmission and acknowledgment on one sender clock delimit a round-trip sample. That local interval avoids needing the receiver's clock offset, while still including the path and processing covered by its endpoints. The guide explains sample admissibility and recovery policy, rather than selecting an operating system clock.

A clock advancing one unit per tick can be monotonic while its ticks occur slightly faster or slower than their nominal duration. A nondecreasing sequence establishes ordering within its contract. Agreement with physical seconds needs separate rate evidence.

For an illustrative constant rate error of plus 20 parts per million, a physical interval of 300 seconds would be reported as 300.006 seconds if all other modeled effects are absent. The clock never moves backward, but its accumulated difference is six milliseconds high.

The rate example separates accuracy from continuity. It does not imply that real interval clocks have a fixed error or that their rates are never disciplined. The supported claim is narrower: monotonicity by itself does not specify the rate error.

Resolution can be isolated with another hypothetical model. Let a perfect-rate interval clock report whole milliseconds by rounding downward. Two events separated by 0.4 millisecond can yield a reported difference of zero or one millisecond, depending on where they fall relative to a tick boundary. The rate is exact in this model, and the readings remain nondecreasing; finite representation alone creates the difference.

Each reported reading lies less than one millisecond below its ideal value. Subtracting two such readings gives a quantization error whose magnitude is less than one millisecond. That bound assumes the declared rounding rule and no other measurement error. It should not be assigned to a clock with an unknown representation or acquisition delay.

Timestamp resolution and the delay between an event and its observation are separate. A finer numeric unit cannot remove latency in the path that obtains the reading. An interval claim needs to identify whether it times the events themselves or the moments at which software observed them.

Event dating and deadlines use different properties

A calendar label is useful when an event must be placed on a shared civil-time record. An interval reading is useful when an application needs a consistent duration or a deadline within one domain. Saving both can preserve event context and local elapsed evidence without treating the two numbers as interchangeable.

For a relative timeout, a deadline formed in the same interval domain can be compared against later readings from that domain. Moving the calendar clock need not change that deadline if the interval contract excludes calendar steps. The condition must be established for the chosen clock rather than inferred from its numeric format.

A request that must occur at a particular calendar label is a different requirement. Corrections to calendar time may affect when that label is reached. Replacing that requirement with an arbitrary interval deadline would change its meaning rather than merely improve the measurement.

The timeout requirement should name its reference: a calendar label, a physical waiting interval, or local progression. A human-readable timestamp can look precise while providing the wrong progression rules for that requirement.

POSIX also distinguishes a timestamp subtraction from a timer service. Its clock_gettime specification says setting CLOCK_REALTIME changes absolute time-service expiration based on that clock, while relative time services retain the requested elapsed interval. The behavior of a timeout therefore needs the actual API contract; calendar-clock arithmetic alone cannot establish how a relative wait is implemented.

Suspend inclusion is a separate property

Consider a hypothetical sequence with ten seconds of awake operation, one hour of system suspend, and five more seconds awake. An interval clock that stops during suspend reports fifteen seconds of progression. Another interval clock that includes suspend reports 3,615 seconds.

Both clocks can remain nondecreasing throughout their specified lifecycle while counting different portions of the history.

A timeout intended to expire after physical waiting may need suspend-inclusive behavior. A measure defined as awake-system progression may intentionally exclude suspend. There is no universal choice without the application's requirement.

This example compares clock progression during suspend. Awake-system progression differs from per-task CPU execution: a process can be inactive while the system is awake and the interval clock continues advancing.

A resumed application should interpret its deadline according to the clock it originally used. Switching from an excluding clock to an including clock without a mapping can create a large artificial change. Using seconds in both domains still requires a mapping between their counted histories.

Linux documents this distinction explicitly. Its kernel timekeeping interface associates CLOCK_MONOTONIC with progression from boot that stops during suspend, and CLOCK_BOOTTIME with progression that includes suspend. CLOCK_MONOTONIC_RAW follows the hardware clocksource without the drift adjustments described for disciplined timekeeping. These are Linux contracts, so another platform needs its own documented clock choice.

Clock domains need an explicit mapping

Two interval clocks can have arbitrary different origins. Suppose clock A reads 1,000 at one event while clock B reads 2,000 at the same physical moment. Five seconds later, A reads 1,005 and B reads 2,005 under their stipulated equal rates.

Within either domain, the difference is five. Subtracting A's initial 1,000 from B's final 2,005 gives 1,005, a meaningless cross-domain interval under the stated definitions. The numerical subtraction is valid arithmetic but lacks a shared origin.

A mapping may require both an offset and a rate relationship. If those clocks drift relative to each other, one captured offset cannot establish the mapping indefinitely. Its uncertainty and validity interval belong with any converted timestamp.

Reboots or domain resets can change an interval origin. A reading persisted before a reset may not be comparable with a new reading merely because both are nonnegative counters. The lifecycle identity is part of the timestamp's meaning. Retaining a boot or domain identifier can expose a reset boundary before a later subtraction is admitted.

Cross-machine timestamps add reference and transport uncertainties. A local monotonic reading does not automatically supply a shared global time coordinate. Interpreting a distributed duration needs an appropriate relationship between domains, with any missing information reported.

The ZT-703S handheld instrument is listed with oscilloscope, multimeter, and waveform-generator functions, waveform storage and export, and nominal 20ppm time-base accuracy. That time-base figure concerns the electrical trace reference described by the listing. It does not specify a computer's calendar correction, suspend behavior, or boot identity. The earlier 20ppm arithmetic remains a hypothetical constant-rate example, rather than a calibration result for this instrument.

A stored trace can provide a local sample-time axis while its file also has a calendar timestamp. Those labels may serve different purposes. Their presence in one file does not create a justified mapping to another computer's interval clock.

The Focusrite Scarlett 4i4 recording bundle listing describes a four-input USB-C interface and recording accessories. An audio record can provide sample-index timing under its acquisition contract. That does not establish a calendar correction history or direct comparability with another machine's monotonic readings.

A duration record can retain the selected clock domain, lifecycle identity, raw start and end readings, and relevant progression rules. If a later analysis finds that the wrong reference was chosen, those details expose what the subtraction actually measured. A bare number of seconds cannot reconstruct the missing contract.