Log Timestamp Normalizer & Sorter

Normalize log timestamps to one format and time zone

Logs pulled from different servers, services, and tools rarely agree on how to write a date. One file says 2025-10-21T17:45:21Z, the next says Oct 21 13:45:21, and a load balancer writes 21/Oct/2025:17:45:21 +0000. This tool finds the timestamp on every line, converts it to a single format and time zone, and can sort the whole log into true chronological order. Everything runs in your browser. The log is never uploaded.

How to use it

1. Paste log lines into the box, open a .log or .txt file, or drop a file onto the tool.
2. Pick an output format. ISO 8601 in UTC is the safest choice for sharing and sorting.
3. Tell the tool what zone to assume for timestamps that don't include one. Server logs are usually UTC, but desktop apps often log in local time.
4. Choose whether each timestamp is replaced, added in front of the original line, or extracted on its own.
5. Turn on Sort by time to merge interleaved logs, then copy the result or download it as a log or CSV file.

Timestamp formats it recognizes

The tool checks each line against the formats below and uses the first timestamp it finds. A time zone written right after the time, such as Z, -0400, +05:30, UTC+2, or an abbreviation like PDT, is read and applied.

How time zones are handled

Every timestamp is first converted to an exact moment in UTC, then written in the zone you pick under Convert to time zone. Timestamps with an explicit offset or zone name keep their meaning no matter what you choose. Timestamps with no zone at all are read in the zone set under Timestamps with no zone are in. The tool counts how many lines relied on that assumption, so you know how much of the result depends on it.

Named zones such as America/New_York or Europe/Berlin follow daylight saving rules, so a naive 2025-07-01 09:00 in New York becomes 13:00Z while 2025-01-01 09:00 becomes 14:00Z. Abbreviations are fixed offsets: EST is always UTC−5 and EDT is always UTC−4. A few abbreviations mean different things in different countries. IST is read as India (UTC+5:30), CST as US Central, and BST as British Summer Time. The tool flags each one it uses so you can check it.

Dates without a year

Classic syslog lines like Jan 1 00:00:03 don't include a year. By default the tool borrows the year from other dated lines in the same log. If there are none, it uses the most recent year that doesn't put entries in the future, the same rule most syslog readers follow. You can also type a year yourself. Either way, it moves to the next year when the log crosses from December into January. A file that starts on December 31 and continues into January comes out in the right order instead of jumping back eleven months.

Ambiguous numeric dates

A date like 03/04/2025 is March 4 in the US and 3 April almost everywhere else. When one of the numbers is above 12, the tool knows which is the day. When both could be either, Auto reads slashes as month first and dots or dashes as day first, and reports how many dates were ambiguous. Set the option to month first or day first if your source is consistent.

Sorting logs chronologically

Merging logs from several machines usually leaves entries out of order, especially when each machine writes in its own local time. Sorting on the converted UTC moment puts them back in the order things actually happened. Ties keep their original order, so lines written in the same millisecond don't get shuffled.

Stack traces and wrapped messages span several lines, and only the first line carries a timestamp. With Keep multi-line entries together on, the lines that follow a timestamped line move with it, so exceptions stay attached to the error that produced them. Lines before the first timestamp stay at the top.

The summary shows the earliest and latest time, the total span, how many entries were out of order, and the largest gap between entries. The timeline chart spreads entries across the span so bursts and silent periods stand out. A dotted red segment marks a stretch with no entries at all.

Why normalize to ISO 8601 UTC?

• It sorts as text. 2025-10-21T17:45:21Z strings sort correctly with a plain alphabetical sort, in any tool.
• No daylight saving surprises. UTC never skips or repeats an hour, so the 1:30 AM that happens twice each November isn't a problem.
• Every tool reads it. Elasticsearch, Splunk, BigQuery, pandas, Excel, and JavaScript's Date all parse ISO 8601 directly.
• Easier incident timelines. When every line uses the same zone, you can line up events from different systems without doing offset math in your head.

Frequently asked questions