Log every timestamp in UTC using the RFC 3339 format, and keep all hosts' clocks synchronized. Without that, events from different systems cannot be put in order, and an incident timeline turns into guesswork about whether the login came before or after the file download.
Why this goes wrong
Incident reconstruction is mostly sorting. You pull events from the load balancer, the application, the identity provider and the cloud audit trail, then line them up. If one source writes local time without an offset, another writes UTC, and a third drifts by four minutes, the merged timeline lies to you.
Common failure modes:
- Local time with no zone, which becomes ambiguous twice a year when clocks change.
- Two-digit years or locale-specific date formats that parse differently in different tools.
- Servers with no time sync, drifting for months.
- Containers that inherit a host clock that was never checked.
Use one format
RFC 3339 is a profile of ISO 8601 for internet timestamps. The shape is a date, a T, a time, optional fractional seconds, and an offset. UTC is written with a Z suffix. The RFC's own examples include 1985-04-12T23:20:50.52Z and 1996-12-19T16:39:57-08:00. It also notes that -00:00 means the UTC time is known but the local offset is not, which is different from Z.
For logs, the simplest policy is to emit UTC with a Z and millisecond precision. Convert to local time only in the display layer. Syslog's RFC 5424 uses the same base with stricter rules: uppercase T and Z, no leap seconds, and at most six fractional digits.
Synchronize the clocks
The OWASP Logging Cheat Sheet is direct about it: synchronize time across all servers and devices. Where you cannot, such as on user-controlled devices, it suggests measuring the offset or recording a confidence level for the timestamp.
Practical steps:
- Run a time sync service on every host and confirm it is actually syncing, not just installed.
- Point everything at the same small set of internal sources.
- Alert when a host's offset exceeds a threshold you choose, such as a few seconds.
- For client-reported times, store both the client time and the server receive time.
Two timestamps are better than one
Logging pipelines add delay. Record the event time (when it happened) and let the collector add an ingest time (when it arrived). Investigations use event time. Pipeline health checks use the gap between the two, which can show a stuck forwarder. We cover that in detecting when a log source goes silent.
A short test
Pick a request that crosses three services and find it in each log. If the three timestamps are not within the network latency you expect, you have found a clock or format problem before an attacker did.
Quick check
Is it acceptable to log local time if the offset is included?
It is valid, but UTC everywhere is simpler and removes an entire class of conversion mistakes. Keep local time for dashboards.
How precise should timestamps be?
Milliseconds are enough for most investigations. What matters more is that every source uses the same precision and the clocks agree.
Sources
Last reviewed: 19 October 2026.
