What should be recorded about date, time and time zone?¶

Record the displayed time exactly, its timezone or UTC offset where shown, and a reliable independent reference time observed at the same moment.

A timestamp belongs to a system and an event¶

Device clocks can be wrong, daylight-saving settings can differ and applications may display local, server or account-specific time. A phone, laptop, router and cloud service can therefore show different values for related activity.

Capture each timestamp with its context: message, login, file, alert, notification or provider event. The same numerical time can describe creation, receipt, display or another stage. Relative labels such as “five minutes ago” require the observation time to be meaningful.

Do not silently convert values. Retain the original representation and state any later normalisation method. Where no timezone appears, treat it as unknown until the relevant system's configuration or documentation establishes otherwise.

Preserve clock differences rather than correcting them¶

Compare the displayed time with an independent source and record the observed offset. Do not adjust the device clock during first response: that can alter logs, file times and synchronisation behaviour.

If the date is obviously wrong, preserve the discrepancy without inventing its cause. Later examination can test clock settings, automatic-time services and event sequences. The first-response record supplies the anchor needed for that work.