Date Format Converter

Switching a date between US (MM/DD/YYYY), European (DD/MM/YYYY), ISO (YYYY-MM-DD), and Unix timestamp formats is one of those data-cleaning tasks that's harder than it should be when working with mixed sources.

Paste a date in any common format and the converter parses it, then outputs in the formats you want. Ambiguous dates (03/04/2024 — is that March 4th or April 3rd?) get flagged with both interpretations so you can pick. ISO 8601 is recommended whenever possible because it's unambiguous and sorts correctly as a string.

Time zones are supported. Without a zone, the input is treated as floating local time. With a zone (Z, +05:00, EST, etc.), conversions to other time zones are computed correctly accounting for DST transitions. Common gotcha: 'EST' is ambiguous because some places use it year-round (Cayman) and some shift to EDT in summer (US East Coast).

The parser tries known formats in order of likelihood: ISO 8601, RFC 2822 (email date format), MM/DD/YYYY, DD/MM/YYYY, YYYY-MM-DD, Unix timestamp (seconds or milliseconds based on magnitude), and a few common variations. The first one that successfully parses wins. For ambiguous inputs like '03/04/2024' (March 4 in US, April 3 in Europe), the parser flags both interpretations and asks you to pick. Date strings with explicit indicators ('March 4, 2024' or '4 March 2024') are unambiguous and parse directly.

The pain this addresses: data in mixed formats from multiple sources. A spreadsheet column has dates as '03/15/2024,' '15-Mar-2024,' '2024-03-15T14:30:00Z,' and the occasional Unix timestamp. Cleaning this for downstream use means converting everything to one consistent format — usually ISO 8601 because it's unambiguous and sorts correctly. The converter handles each format individually; for batch conversion of many dates, a script using the same library is more efficient than running them one at a time.

Worked example: input '03/04/2024'. The parser flags this as ambiguous and offers two interpretations: March 4, 2024 (US) and April 3, 2024 (Europe). You pick US. Output in ISO 8601: '2024-03-04'. Output as Unix timestamp: 1709510400 (assuming UTC midnight). Output in RFC 2822: 'Mon, 04 Mar 2024 00:00:00 +0000'. The same date represented in three formats — useful for putting into different systems that prefer different forms.

Where time zones get tricky: the same instant has different date representations in different zones. '2024-03-04 23:00:00 PST' is the same instant as '2024-03-05 07:00:00 UTC' — different date in different zones. Code that treats dates without zones as 'just a date' often produces off-by-one errors when crossing zone boundaries. The converter accepts inputs with explicit zones, treats unzone'd inputs as floating local time, and warns when conversion crosses a date boundary. For data hygiene, store everything in UTC and convert to local only at display time. This is the pattern most modern apps follow because the alternatives produce subtle bugs that show up at midnight.