Build a UTC incident timeline from Unix timestamps

Problem

Distributed incident evidence rarely shares one clock or one unit. An application can record epoch seconds, a browser can send milliseconds, a database can commit microseconds, and a trace collector can receive nanoseconds. Fields called created_at, sent_at, received_at, and indexed_at may describe different stages of the same event, while server clock skew and network delay can reverse their apparent order. Converting everything to a readable date is only the first step: a defensible timeline must keep the exact epoch value, source system, semantic field, UTC normalization, precision, and uncertainty together. It must also distinguish recorded order from proven causal order and use local time only as a labeled translation for user evidence.

Sources and standards

These authoritative references define the formats or security boundaries used in this workflow. Tool-specific verification is documented separately above.

• RFC 3339: Date and Time on the Internet: Timestamps

  RFC Editor / IETF

When to use this

• An incident spans application logs, a queue, a database, an API gateway, and browser or mobile evidence.
• The same request has event, send, receive, commit, and ingest timestamps that must not be treated as one field.
• Two events share the same millisecond date display but have different microsecond or nanosecond ordering.
• A user reports a local clock time that must be compared with UTC backend evidence and daylight-saving rules.
• You need a ticket or postmortem table that records uncertainty instead of presenting a guessed sequence as fact.

Steps

1. Step 1

   Define the incident window and anchor

   Choose a known UTC anchor such as a deploy, gateway response, database transaction, or monitored alert. Record its source and confidence before adding less certain events.

2. Step 2

   Label each clock and timestamp meaning

   For every value, record the producer and whether it represents event creation, client send, server receive, database commit, queue acknowledgement, or later ingestion. Do not merge these meanings into a generic time column.

3. Step 3

   Confirm each source unit

   Use schema or code documentation for seconds, milliseconds, microseconds, or nanoseconds. If a copied excerpt mixes units, use Auto and review each result; otherwise choose one explicit unit for the source batch.

4. Step 4

   Normalize to UTC while retaining exact epoch

   Convert the bounded excerpts and place ISO UTC beside the original exact epoch string. Do not discard sub-millisecond digits just because multiple events share the same .123Z date display.

5. Step 5

   Sort within comparable clock domains

   Exact epoch values can order events generated by a sufficiently synchronized clock. Across different hosts, note NTP status, known drift, client clock quality, and network delay before treating a small difference as meaningful.

6. Step 6

   Compare transport and protocol evidence

   Use HTTP Date, Age, cache, request ID, and tracing headers when available, and keep queue or database sequence evidence beside timestamps. These fields can support or challenge the proposed order without making timestamps causal proof.

7. Step 7

   Translate for users only after the UTC review

   Keep the technical timeline in UTC. Add the converter's named browser-local IANA zone as a separate column when matching a screenshot or report, and record the zone rather than writing an unlabeled local clock time.

Example

client sent_at=1704067200123 (milliseconds)
gateway received_at=1704067200.128 (seconds)
database committed_at=1704067200132456 (microseconds)
trace indexed_at=1704067200139000000 (nanoseconds)

00:00:00.123000Z | client send | client clock; verify skew
00:00:00.128000Z | gateway receive | server clock
00:00:00.132456Z | database commit | exact microseconds
00:00:00.139000Z | trace ingest | collector time
Observed order is consistent, but cross-host timestamps alone do not prove causality.

Common mistakes

FAQ