Write every log timestamp in UTC using the RFC 3339 format, with fractional seconds, and keep all hosts clock synchronized. Mixed time zones and drifting clocks are the quiet reason incident timelines fail to line up, and they are cheap to prevent.
The problem with local time
Picture an incident that touches an API in one region, a database in another and a vendor webhook. If each log uses its own local time and its own format, you spend the first hour converting instead of investigating. Daylight saving changes make it worse, because an hour repeats or disappears.
The fix is to pick one reference, UTC, and never log anything else.
What RFC 3339 gives you
RFC 3339 is an internet profile of ISO 8601 for timestamps. The general shape is year, month, day, a T, hours, minutes, seconds, optional fractional seconds, then a UTC designator. The letter Z means UTC with an offset of zero.
2026-10-19T09:14:03.221Z
A numeric offset such as -04:00 is allowed, and the RFC is clear that it is local time minus UTC. A line with an offset still names an exact instant, but I would still normalize to Z at write time so sorting as text matches sorting by time.
The RFC also notes that an offset written as -00:00 means the UTC time is known but the local offset is not. That is rare in application logs, but you may see it from some devices.
Use fractional seconds
Within one second a service can write dozens of lines. Millisecond precision keeps ordering sensible. Be honest about what it proves: timestamps from two machines are only comparable to the accuracy of their clocks.
Keep clocks in sync
The OWASP logging guidance says to synchronize time across all servers and devices. Where you cannot, such as on devices your customers control, it suggests measuring the offset or recording a confidence level for the timestamp.
In practice that means:
- run a time sync service on every host and container node
- alert when a host drifts beyond a threshold you choose
- for mobile and browser clients, log the server receive time as well as the client time
Two timestamps are better than one for client events
A phone that is offline for an hour will report events late. Keep event_time, set by the client, and received_time, set by your server. Search on received_time for operations, and use event_time for analysis, treating it as untrusted because the user controls the device clock.
Store a time zone only when you need it
If a report needs "9am local time for the customer", store the customer's zone as data. Do not derive it from the log timestamp.
Quick check
Is Z the same as +00:00?
Both mean UTC for practical purposes. RFC 3339 recommends uppercase Z for UTC, and it keeps lines consistent.
Can I trust a client timestamp?
No. Record it for context, but order and alert on the time your own server received the event.
Sources
Last reviewed: 19 October 2026.
