How should time uncertainty be reported?¶

Report timing only as precisely as the records support. State the original value, what system and event stage it represents, any conversion applied and the specific source of uncertainty.

Match the wording to the limitation¶

Uncertainty can arise from an unknown zone, clock error, limited precision, delayed upload or an unclear field definition. These affect conclusions differently: a one-minute clock range is not the same as an unknown event stage.

Useful formulations include “recorded by the server as 14:05 UTC”, “approximately 14:05”, or “between 14:05 and 14:07”. If a repeated daylight-saving hour creates two valid local interpretations, show both unless other evidence resolves them. If equal or unreliable timestamps do not establish order, say so directly.

Keep correction and inference visible¶

Explain the evidence for any applied offset and the period over which it is supported. Do not extend a single clock comparison across a longer period if drift or synchronisation could have changed the error.

The limitation belongs wherever timing supports the investigative conclusion, not only in a technical appendix. Clear uncertainty preserves the distinction between a system-recorded value and an inferred real-world time.