Reformat Dates in a TSV
Normalise a date column so it sorts, filters, and loads correctly. The reason to convert to ISO 8601 specifically: 2026-07-19 sorts correctly as plain text, is unambiguous about which number is the month, and is what every database accepts without a format string. 19/07/2026 has none of those properties. Rows that can't be parsed are reported rather than silently mangled.
How to use
- Paste or drop the file and name the date column — comma-separate for several.
- Set read as explicitly if your dates are slash-separated. This is the important step; see below.
- Pick the output format. ISO date is the right default for anything that isn't a human-facing report.
- Check the failure count in the status line — it names the first value it couldn't parse, which usually explains the rest.
Day-first or month-first: the one decision that matters
03/07/2026 is the 3rd of July to most of the world and the 7th of March in the United States. Nothing in the value tells you which, and getting it wrong shifts dates by months without any error appearing anywhere. In auto mode the tool uses the only real evidence available: if one component is greater than 12 it must be the day. When both are 12 or under it assumes month-first, matching the Date.parse convention — which means a European file with early-in-the-month dates will be misread unless you select day-first.
So: if your source is European, set day first explicitly, every time. The pathological case is a file with a mix of both conventions, which happens when data was entered by hand in different locales. No parser can fix that; you have to find the rows with a locale hint from elsewhere in the record, or accept the loss.
No timezone arithmetic
Dates are parsed into plain year/month/day/time components and re-emitted from those, without ever being converted into an absolute instant in a timezone. This is deliberate: date-only values that go through a Date object shift by a day for anyone west of UTC, which is one of the most common and most maddening data bugs there is. Here, 2026-07-19 in gives 19/07/2026 out, in every timezone on earth.
The exception is the epoch formats, which are by definition absolute — those are computed as UTC. Converting a date-only value to epoch seconds gives you midnight UTC on that day.
What it recognises
ISO (2026-07-19, with optional T or space time), slash- dot- or dash-separated numeric dates, 19 Jul 2026 and Jul 19, 2026 with English month names, compact 20260719, and 10- or 13-digit epoch values in auto mode. Two-digit years map to 2000–2069 for 00–69 and 1970–1999 above that. A time portion is carried through if the output format has room for it; if not, it's dropped. Non-English month names are not recognised.
FAQ
Why do my times all show 00:00:00?
Because the source values are dates with no time component, and inventing one would be worse. If the source does have times and they're being dropped, check that they're in a recognised position — a time immediately after the date, separated by a space or a T.
Can I sort by date afterwards?
Convert to ISO first, then sort in text mode — ISO strings sort chronologically as text, which is the format's main practical virtue. Sorting a US or EU format column will order it by month or day, not chronologically.
What about timezone offsets in the input?
An offset like +02:00 is ignored rather than applied — the local wall-clock components are kept as written. If you need genuine timezone normalisation, that's a job for a script with a real date library, not a text tool.
Can it validate dates rather than reformat them?
Set if unparseable to write UNPARSED and the bad rows become visible in the output; filter rows with col = "UNPARSED" then pulls them out for inspection. Note that impossible-but-well-formed dates like 2026-02-30 are accepted by the parser.
Privacy
100% client-side. No upload. See the privacy policy.