What date, time and time zone does this timestamp represent?¶
An IP address normally needs a precise timestamp before a provider can identify who was using it. First establish exactly what the displayed time represents.
Identify the time zone¶
A record showing 24 July 2026 14:30 is incomplete unless you know the time zone.
Check for:
Z, which normally means UTC;- an offset such as
+01:00; - a named zone such as UTC, GMT or BST; or
- product documentation explaining how the system stores and displays time.
“UK time” is not precise enough. The UK normally uses GMT in winter and BST, one hour ahead of UTC, in summer.
Computer systems often store time in UTC but display it using the settings of the user, browser or device. An exported report may therefore show a converted value rather than the stored one.
Establish which event was timed¶
A system may record when:
- the activity occurred;
- a server received it;
- an alert was created; or
- a report was exported.
Use the field name, system owner and product documentation to identify the event. Do not assume every time shown on the page refers to the same stage.
Keep all available precision¶
Preserve seconds and milliseconds where they exist. With CGNAT or another shared-address system, several customers may use the same IP address within one minute.
The source port and protocol may also be needed to identify the correct connection.
A useful written format is:
24 July 2026 at 14:30:17 UTC
Keep the original value as well as any converted time, and record how the conversion was made.
Then consider clock accuracy¶
Once you know what time the record claims to show, consider whether the system clock was accurate. That is a separate check.
Operational takeaway
Record the full date, time, precision, time zone and UTC offset. Keep the original timestamp and make any conversion explicit.
