Measure elapsed time in the clock’s own domain

Choose the time question first

A service record may need two answers: when an operation happened on a calendar, and how long it took. One field rarely answers both reliably. A machine clock can be adjusted during an operation; a performance counter can lack a calendar origin. Before interpreting an exported difference, identify the question, the endpoints and the clock that supplied each value.

W3C’s High Resolution Time Working Draft of 1 September 2026 separates an adjustable wall clock from a monotonic clock used for measurement. Its browser monotonic clock belongs to an execution and cannot establish comparisons across different executions. Python’s time.monotonic documentation likewise says the reference point is undefined and valid use concerns differences between readings. Apply each API’s documented scope rather than treating all numeric times as interchangeable.

A fictional operation crosses a clock adjustment

This hypothetical fixture records a wall-clock start at 10:00:00.800 and an end at 10:00:00.300. A backward clock correction occurred during the operation. Subtraction gives minus 500 milliseconds. The same operation’s compatible monotonic readings are 20,000 and 20,040 milliseconds, giving 40 milliseconds. These invented values illustrate two representations; they are not a benchmark or a measurement from a company archive.

Preserve the wall-clock readings and the adjustment evidence. Replacing the negative difference with 40 without recording its different origin would conceal the reconciliation. A recipient may accept the monotonic duration for this bounded operation while retaining an unresolved calendar placement. If no compatible counter pair was actually captured, the correct duration may remain unknown.

Make the clock boundary part of the record

A practical duration register names the clock API, unit, execution or host identity where relevant, start/end event definitions, counter reference and reset rule. Keep any wall-clock association separately. Record precision and resolution as supplied; adding displayed decimal places cannot create finer observations. Equal consecutive readings may reflect the available resolution rather than an instantaneous business operation.

An application restart, new browser execution or different acquisition device should prompt a continuity check. The exact boundary depends on the documented implementation. Some APIs share a monotonic clock more widely than one process, so a blanket rule based only on process identity would also be unsafe. Require positive evidence for the pair actually used.

Test the receiving calculation with synthetic resets, equal readings, missing endpoints and a clock adjustment. The exporter should preserve an unresolved state when the contract cannot support a subtraction. Specify whether the intended metric includes sleep, queued time or only active execution; those are different definitions to confirm in the selected API and workflow.

Report the supported duration and its limits

For the fictional operation, the accepted 40 ms result names the compatible monotonic pair and its scope. It does not restore the adjusted wall clock or place an operation from another host in causal order. A receiving report should retain the source readings, calculation and exception reason, rather than publish one unexplained duration column.

Use the inventory to state how much of the proposed record history has compatible endpoint pairs. A sampled check should report the sample and unresolved cases separately from archive-wide coverage. Assign missing clock documentation to the application owner before promising a latency dataset. Calendar interpretation and historical prediction-time availability still need their own reviews; this check concerns the validity of the elapsed-time pair.