Can I trust the timestamp and the system clock?¶
title: "Can I trust the timestamp and the system clock?" card_id: "IP-031" status: "complete" source_document: "https://docs.google.com/document/d/1n4qB7xLbICWSGSW4rKchXtrzq32BIvsa-LYeezOAVyA/edit?usp=drivesdk"
Can I trust the timestamp and the system clock?¶
Can I trust the timestamp and the system clock?¶
A timestamp can include the exact date, time, time zone and even milliseconds—and still be wrong.
That is because a timestamp normally depends on the clock used by the system that created it.
Computer clocks aren’t automatically perfect.
A device may have been set to the wrong time or time zone. Its clock may gradually have drifted. Automatic time synchronisation may have failed, or somebody may have changed the clock manually.
Different parts of the same service can also use different clocks.
A user’s device might record one time, the application another and the service’s central server a third. A security platform may then generate an alert using its own timestamp.
The important question is therefore not simply, “What time is shown?”
It is, “Which system created this timestamp, and how reliable was that system’s clock?”
Server-generated timestamps are often more reliable than times supplied by a user’s device, particularly where the server is regularly synchronised with a trusted time source.
But that shouldn't simply be assumed.
Clock errors can take different forms.
A clock might be consistently five minutes fast. That is sometimes called a clock offset.
Alternatively, the difference may increase or decrease over time because the clock is drifting. A correction that works for one event may therefore be inaccurate for an event recorded several days later.
There may also be delays between the activity and the timestamp.
A device could perform an action at one time, send the information later and have the server record when it was received. Queues, network delays and offline devices can all create differences between the event time and the recorded time.
One way to assess a timestamp is to compare it with another event whose time is independently known.
For example, the record might be compared with server logs, message-receipt times, CCTV, telephone records or another system involved in the same activity.
If several records show the same consistent difference, it may be possible to identify and explain the clock error.
This matters particularly when an IP address is being resolved to a subscriber.
With dynamic addressing or CGNAT, the same public IP address can relate to different customers at different times. A clock error of minutes—or sometimes seconds—could produce the wrong result.
A timestamp shouldn't be rejected merely because the clock may be imperfect. But its reliability needs to be understood and any identified discrepancy recorded.
A precise timestamp tells you exactly what time the system claimed the event occurred. It doesn't, by itself, prove that the system’s clock was correct.