How is this different from a plain UTC-to-local converter?

This tool scans a whole log at once, extracts a timestamp from every line it can, converts each one to your browser’s local time, and adds a compact elapsed-time delta compared to the previous successfully parsed line. It is built for scanning incident timelines, not converting a single date.

How do I know whether a timestamp was explicit UTC or just assumed?

The summary above the output shows counts for explicit UTC, explicit offsets, and assumed UTC/local/timezone lines. A timestamp with a trailing "Z" or a numeric offset like "+02:00" is always explicit. A bare timestamp with no offset uses whichever "Unzoned timestamps are" assumption you selected.

What happens to lines that don’t have a timestamp?

Lines with no detected timestamp, or with a timestamp that fails validation (invalid calendar date, invalid offset, or a nonexistent DST-gap wall time), are left completely unchanged. They also don’t reset or advance the elapsed-time comparison, so a stack trace between two log lines won’t break the delta.

Can I use my own log format?

Yes. Switch to custom mode, supply a regular expression containing a named group (? ...), and a matching date-format pattern using tokens like yyyy, MM, dd, HH, mm, ss, and XX for an offset. The format tokens panel in the tool includes a ready-to-copy example for Apache-style logs.

Is any of my log data uploaded anywhere?

No. Parsing, timezone conversion, and formatting all run locally in your browser using built-in JavaScript date and Intl APIs. Nothing is sent to a server, and nothing is stored after you leave the page.

Log Timestamp Converter & Time Delta Annotator

Turning scattered log timestamps into a readable timeline

Paste any multiline log excerpt and this tool appends a browser-local, human-readable time and a compact elapsed-time delta to every line where it finds a valid timestamp. Lines without a timestamp, like stack traces or plain text, are left completely unchanged and never break the running comparison. Pick Auto-detect common formats for the grammars below, or switch to Custom regex + format for anything else, then click Annotate logs. Nothing you paste is uploaded anywhere; parsing, timezone math, and formatting all run locally in your browser.

Explicit UTC versus an assumed timezone

A timestamp that ends in Z or carries a numeric offset like +02:00 or -0400 is unambiguous: the tool reads it as explicit UTC or an explicit offset and converts it directly. A bare timestamp with no offset, such as 2026-07-21 14:03:20, is inherently ambiguous. No software can recover the author's intended timezone from the digits alone, so the Unzoned timestamps are selector lets you choose how to interpret it: as UTC (the default), your browser's current local time, or a specific IANA timezone such as Europe/Berlin. That choice only affects interpretation of the source value; the output is always rendered in your browser's current local timezone, shown just above the input box.

Supported built-in formats

Automatic detection recognizes ISO 8601/RFC 3339 timestamps with a T or space separator and an optional millisecond fraction, both with and without a zone; Apache/Nginx access-log timestamps like [21/Jul/2026:14:03:20 +0000]; and standalone Unix epoch values, either 10-digit seconds or 13-digit milliseconds, bounded so they don't match digits embedded inside longer identifiers. When several patterns could match the same position, the earliest and most specific candidate wins, and only the first timestamp on each line is used.

Custom regex and format tokens

For anything outside those grammars, switch to custom mode. Your regular expression must contain a named capture group, (?<timestamp>...), and the first match on each line is what gets parsed. A companion format pattern then parses that captured text deterministically, using tokens like yyyy, MM, MMM (English month abbreviations), dd, HH or hh with a for a meridiem, mm, ss, fractional-second tokens, and XX/XXX for a compact or colon-separated offset. This deliberately avoids handing arbitrary captured text to the JavaScript engine's built-in date parser, whose behavior for non-standard formats varies by browser.

Relative-time semantics

Every successfully parsed line is compared to the previous successfully parsed line, even when unrelated or invalid lines sit between them. The first valid timestamp is labeled start; an identical timestamp shows same time; later timestamps get a leading + and earlier ones a leading -. Small gaps render as milliseconds or seconds with trailing zeroes trimmed, while gaps of a minute or more show the two largest non-zero units, for example +1m 37s or +2h 4m.

DST ambiguity and nonexistent times

Interpreting an unzoned timestamp against an IANA timezone can hit a daylight-saving transition. During a fall-back overlap, the same wall-clock time occurs twice; this tool picks the earlier of the two instants and counts it as an ambiguous wall time in the summary. During a spring-forward gap, the wall-clock time never occurred at all, so that line is reported as invalid rather than silently shifted to a neighboring hour.

Debugging and incident-response examples

This tool is built for scanning an incident timeline quickly: paste server logs that mix a UTC-stamped upstream service with an unzoned application log, choose the application's known timezone for unzoned lines, and immediately see which request came first and how long each step took, without manually converting every timestamp by hand. It is equally useful for lining up client-reported local times against server UTC logs when triaging a bug report, or for spotting an unusually long gap between two log lines during a performance investigation.