Normalize Timestamps in JSONL
One file, four time formats, because three services wrote it. Epoch seconds here, epoch milliseconds there, an ISO string with an offset in a third field, and a 2026-08-16 12:30:00 that isn't valid ISO at all. This converts them all to one format, either across the fields you name or across every key that looks like a timestamp.
Normalize
What auto-detection looks for
With the field list blank, any key whose name contains ts, time, timestamp,
date, datetime, created, updated, modified,
expires or ends in _at is treated as a timestamp — provided its value is a string or a
number. The status bar lists exactly which keys were touched, so you can confirm it found what you meant and
nothing else. If it grabbed a field it shouldn't have, name the fields explicitly instead; the list is exact and
supports dotted paths.
The seconds-versus-milliseconds problem
1755345000 is August 2026 read as seconds and January 1970 read as milliseconds. Auto mode uses
magnitude: under 1e11 is seconds, up to 1e14 is milliseconds, above that microseconds. That rule is right for
every timestamp between 1973 and 5138, which is every timestamp you will ever see in practice — but it is a guess,
and if a single field in your file uses a different unit from the rest, auto will convert each one according to
its own magnitude and you will get a mixture. When you know the unit, set it.
String parsing accepts anything the browser's Date understands — full ISO 8601 with or without an
offset, RFC 2822, and the common YYYY-MM-DD HH:mm:ss form, which is rewritten to ISO before parsing
because not every engine accepts the space. A string with no offset is read as UTC when it is ISO-shaped and as
local time otherwise; that ambiguity is in the source data, not in the conversion, and it is the main reason to
prefer ISO with an explicit Z everywhere.
Which output format to pick
ISO 8601 UTC for anything that will be read by a human or another system — it sorts
lexicographically, carries its time zone, and every language parses it. Epoch seconds or
milliseconds when the consumer is arithmetic. Date only for partitioning and
grouping, remembering that it truncates in UTC, so an event at 23:30 in Tokyo lands on the previous day.
SQL datetime for a COPY or LOAD DATA into a column that has no time
zone. Local with offset only when you know the reader shares this machine's zone.
Privacy
Nothing is uploaded. The whole thing runs in this tab, in your own browser. That matters here more than on most tool sites — training data is usually the most sensitive file a team owns.
Frequently asked questions
Why did some values fail to parse?
Usually a format the browser does not recognise — 16/08/2026 is ambiguous and rejected, and so is a locale-specific month name. The status bar counts them; switch the failure mode to leave as they are, then filter for the surviving originals to see what they look like.
Does it change the field name?
No, only the value. Renaming is Rename keys.
Can it convert to a different time zone?
Only UTC or this browser's local zone. Arbitrary zone conversion needs a time-zone database that would have to be downloaded, which would break the offline guarantee — convert to epoch here and shift in your pipeline.
What about timestamps nested inside arrays?
Auto-detection walks into arrays as well as objects when search nested objects is on, so a timestamp inside a list of events is found. Explicit dotted paths address one location and do not iterate arrays — use events[0].ts for a fixed index, or leave the list blank.