Date Format Converter
Parse any date input and format it with a custom pattern.
Overview
The Date Format Converter parses almost any date string you throw at it — ISO 8601, RFC 2822, US M/d/yyyy, European dd.MM.yyyy, Unix epoch seconds — and re-emits it using a custom .NET format pattern. Paste a timestamp, pick or type the output pattern, and you get the same instant rendered the way your downstream system wants it.
Useful for data engineers normalising CSV exports between regions, developers converting between API serialization formats, content editors localising a blog post date, and analysts reformatting an SQL dump for a presentation slide.
How it works
Parsing tries a cascade of well-known formats in order: ISO 8601 (with and without time and offset), RFC 1123, RFC 2822, common locale-specific patterns, and finally Unix epoch seconds and milliseconds. The first parser that succeeds wins. The resulting instant is rendered using the .NET custom-format-string syntax — yyyy, MM, dd, HH, mm, ss, fff, K, zzz, and so on — which is a superset of the C99 strftime tokens most developers already know.
Time zones are preserved when the input carries an offset, and an explicit zone field lets you shift the displayed instant to a target IANA zone like Europe/London or America/New_York without altering the underlying UTC moment.
Examples
1747588800 → 2025-05-18T16:00:00Z (epoch seconds)
"May 18, 2026" → 2026-05-18
"2026-05-18T14:30Z" → "Mon, 18 May 2026 14:30 UTC" (RFC 1123)
"18/05/2026 14:30" → 2026-05-18T14:30:00+00:00 (ISO 8601)
FAQ
What format tokens does it support?
The full .NET custom date-format specification: yyyy, MM, MMM, MMMM, dd, ddd, dddd, HH, hh, mm, ss, fff, tt, K, zzz. These cover every common ISO 8601 and RFC 5322 pattern.
How does it disambiguate 01/02/2026?
The parser tries the user-locale order first, then falls back to ISO order. To avoid ambiguity entirely, use ISO 8601 (2026-01-02) in your input — it is recognised globally.
Can it parse Unix epoch values?
Yes. Ten-digit numeric input is treated as seconds-since-epoch and thirteen-digit input as milliseconds-since-epoch, matching the JavaScript Date.now() convention.
Does it handle time zones?
If the input includes an offset (+02:00 or Z), it is preserved. If not, the value is treated as the zone you selected for output.
Are abbreviations like "EST" recognised?
Zone abbreviations are ambiguous (EST means several different zones around the world) so the tool accepts only numeric offsets and IANA zone IDs.