Can I trust the timestamp and the system clock?¶
A precise timestamp can still be wrong if the system clock was wrong. Check the clock when timing could change the subscriber result, event sequence or interpretation of the evidence.
Where the time came from¶
Start by identifying which system created the timestamp. A single activity may produce times from:
- the user’s device;
- an application;
- a central server;
- a firewall or security platform; and
- an alerting or reporting system.
Server-generated times are often synchronised centrally, but confirm this with the system owner where timing matters.
Common timing problems¶
| Issue | What it means |
|---|---|
| Wrong time zone | The clock may be accurate but displayed or interpreted in the wrong zone |
| Clock offset | The system is consistently fast or slow by a fixed amount |
| Clock drift | The difference grows or shrinks over time |
| Processing delay | The record shows when data was received or processed rather than when the activity occurred |
| Manual change | A user or administrator altered the clock |
Check against another known event¶
Compare the timestamp with an independently timed record from the same sequence, such as:
- a server or platform log;
- message receipt time;
- telephone or access-control records;
- CCTV; or
- another device involved in the event.
If several events show the same difference, record the offset and how it was established. If the difference changes over time, avoid applying one fixed correction to every event.
When this matters most¶
Timing deserves early attention when dealing with dynamic addressing, CGNAT or a tightly timed sequence. A difference of minutes - or sometimes seconds - can point to another connection.
If the discrepancy is small and cannot affect the investigative decision, record it proportionately and carry on.
Operational takeaway
Identify the system that created the time, compare it with a known event where necessary, record any offset and use the corrected timing consistently.
