Timezone Q&A
Why do incident teams use UTC?
Incident teams use UTC because it is stable, sortable, and independent of daylight-saving changes. It reduces confusion when engineers, logs, alerts, and vendors are spread across regions.
UTC is the audit trail
Logs and postmortems are easier to compare when every timestamp uses the same reference timezone. A good incident timeline should let someone reconstruct the order of events without knowing where each engineer was sitting.
Humans still need local time
Use UTC for system records, then translate to local time for on-call handoffs and live coordination.
Do not mix formats
A timeline that mixes UTC, PST, and local calendar display without labels creates avoidable incident confusion.
How to share UTC with non-engineers
Keep the incident record in UTC, then add a local translation for customer calls, leadership updates, or support handoffs. Do not replace the source timestamp with a local time after the fact. That makes screenshots, logs, and postmortems harder to compare when teams review the incident later.
Examples
- A log line at 2026-06-14 09:00 UTC sorts correctly across every engineer location.
- Customer updates can still translate UTC into local time after the technical timeline is fixed.
- A screenshot that says 01:30 local time can be ambiguous during clock changes; 01:30 UTC is not.
Before you send it
- Keep incident timelines in one timezone.
- Label every timestamp in postmortems and customer updates.
- Translate UTC for handoffs instead of changing the source timeline.
- Before publishing a postmortem, scan for unlabeled local times and convert them back to UTC.
- When vendors send local timestamps, record their timezone before merging the events into the main timeline.
- If a stakeholder needs local time, add it beside UTC rather than replacing the UTC source record.