How should time uncertainty be reported?¶

Time uncertainty should be reported openly, specifically and in proportion to what is known.

The purpose is not to weaken the evidence. It is to prevent a system-recorded time from being presented as more exact than it is.

Avoid this assumption: That investigators must choose one precise time even where the source does not support that precision. They should not.

Uncertainty may arise because the time zone is unknown, a device clock was wrong, the event was uploaded later, timestamps have only second-level precision or the field represents processing rather than user action.

The report should identify the original timestamp, the system that produced it and what the field is understood to mean. State any conversion applied and preserve the original value.

Where an offset is established, explain the evidence supporting it. For example, several device events may consistently appear two minutes ahead of a reliable server clock. If the offset may have changed, do not apply one fixed correction across the whole period.

Use wording that reflects the evidence. An event may have occurred “at approximately 14:05”, “between 14:05 and 14:07”, “recorded by the system as 14:05 UTC” or “displayed as 15:05 local time”.

If two possible local times exist because of a daylight-saving change, report both unless another record resolves the ambiguity. If sequence is uncertain, say that the available timestamps do not establish a reliable order.

Avoid hiding uncertainty in technical appendices while using exact language in the main conclusion. The limitation should appear wherever timing supports an investigative proposition.

Operational takeaway¶

Time uncertainty should be reported by preserving the original value, explaining the clock and field, recording conversions and using language that matches the actual precision and reliability of the evidence.