How should timestamp uncertainty be reported?¶

Timestamp uncertainty should be reported clearly wherever timing supports sequence, attribution, alibi or outcome.

The report should preserve the original value and explain why the time may not be exact.

Avoid the dangerous assumption¶

The dangerous assumption is that a timestamp with seconds or milliseconds can always be presented as a precise real-world time.

It cannot.

Uncertainty may arise from the source clock, time zone, daylight-saving conversion, clock drift, buffering, delayed upload, ingestion delay or the meaning of the timestamp field itself.

State which system produced the time and whether it represents event creation, receipt, processing, completion or ingestion. Record the original zone or offset and any conversion applied.

Where an offset has been established, explain how. Do not apply one correction across the whole period unless the evidence supports a stable offset.

Use wording that reflects the evidence. The event may have been “recorded by the source system as 14:05:12 UTC”, “approximately 14:05 local time” or “within the same recorded second”.

If order cannot be resolved, say so. Do not add artificial precision or silently choose one timestamp over another.

Where a daylight-saving transition creates two possible local times, preserve the ambiguity unless another reliable source resolves it.

Also state whether the uncertainty affects the investigative conclusion or merely the presentation of the sequence. The limitation should appear in the main analysis, not only in a technical footnote, if it affects the conclusion.

Operational takeaway¶

Report timestamp uncertainty by preserving the original value, identifying its clock, zone and event stage, documenting conversions and matching the wording to the actual precision and reliability.