Extract and convert timestamps from API logs

Problem

An API trace can contain created_at in seconds, a browser event in milliseconds, a database value in microseconds, and a tracing field in nanoseconds on adjacent lines. The same snippet can also contain status codes, durations, request IDs, tokens, and user data. Copying every number into separate converters loses the field and line context needed to validate the result, while guessing a unit from today's common digit count can misclassify historical or padded values. A useful extraction workflow must keep the sample bounded, redact secrets, preserve context, report its heuristic, and retain exact sub-millisecond values without claiming that a readable millisecond date contains every digit.

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

• A copied API log, webhook, queue event, or JSON fragment contains several epoch-shaped values.
• Different producers document seconds, milliseconds, microseconds, or nanoseconds in the same debugging session.
• You need to keep created_at, processed_at, received_at, and source line numbers attached to the converted rows.
• A 12-digit historical value or another ambiguous value needs an explicit unit rather than a current-date guess.
• You need a redacted conversion report for a ticket without uploading the log text to a conversion server.

Steps

1. Step 1

   Copy the smallest useful context

   Keep the field name, event type, and a few neighboring lines needed to identify each value. Remove authorization headers, cookies, raw JWTs, email addresses, and unrelated user data before placing the snippet in any debugging tool.

2. Step 2

   Preserve field names and line boundaries

   Do not reduce the sample to an unlabeled list of numbers. Names such as created_at, duration_ms, sequence_id, and received_at help distinguish timestamps from counters and explain which clock produced each value.

3. Step 3

   Check the documented source unit

   Read the API schema, database column, tracing documentation, or producer code when available. Auto mode uses 9-11 integer digits for seconds, 12-14 for milliseconds, 15-17 for microseconds, and 18 or more for nanoseconds, but that heuristic is not source metadata.

4. Step 4

   Convert the bounded sample

   Paste at most 200,000 UTF-8 bytes, 200 lines, and 100 timestamp candidates. Leave Input unit on Auto only for mixed ordinary values; select one explicit unit when every candidate follows a documented schema.

5. Step 5

   Read unit and precision warnings

   Review every detected unit and skipped line. Exact epoch strings preserve microseconds and nanoseconds, while ISO, UTC, and local Date displays stop at milliseconds and warn when a sub-millisecond remainder exists.

6. Step 6

   Keep UTC output mapped to the source

   For each useful row, retain the original field name, source line, chosen or detected unit, exact epoch value, and ISO UTC result. Use the browser-local IANA zone only when matching a user's displayed time.

7. Step 7

   Validate one anchor outside the snippet

   Compare a known deploy, database record, signed event, or server log header with one converted row. A plausible date alone does not prove that the field was a timestamp or that auto-detection selected the documented unit.

Example

INFO created_at=1704067200 status=200
INFO updated_at=1704067200123 duration_ms=42
DEBUG processed_at=1704067200123456 request_id=req_demo
TRACE received_at=1704067200123456789 retries=3

1704067200 | seconds | 2024-01-01T00:00:00.000Z
1704067200123 | milliseconds | 2024-01-01T00:00:00.123Z
1704067200123456 | microseconds | exact 1704067200.123456 s | date display .123Z
1704067200123456789 | nanoseconds | exact 1704067200.123456789 s | date display .123Z

Common mistakes

FAQ