Date Format Converter: ISO, US, and European Formats

Introduction: why one numeric date can mean two different days

Write 02/03/2024 and you have said almost nothing. A reader in Chicago sees the second of March; a reader in Munich sees the third of February. The digits are identical, but the field order flips, and there is no way to recover the intended meaning from the string alone. This date-format converter takes one calendar date, lets you identify the order you meant, and returns that same day in every common notation so you can use the version a form, database, or colleague expects.

It also does the thing most converters quietly skip: when the digits genuinely support more than one real calendar day, it says so instead of guessing. Auto-detect mode builds every reading the string allows, throws away the ones that are not real days, and reports an ambiguity when two or more survive. That distinction — resolvable versus genuinely ambiguous — is the whole point of the Ambiguity Desk game further down the page.

Date formats this converter reads and writes

This date converter handles the same three calendar fields — year, month, and day — while changing the order in which they are written, plus the two alternative ISO 8601 representations that number days rather than naming months.

ISO is especially useful for machine-readable dates because its fields run from the largest unit to the smallest. Alphabetically sorting a column of ISO date strings also places the dates in chronological order, without first parsing them as dates. That property is a major reason systems commonly store calendar dates in this form.

How to use the date format converter

Type the date exactly as it appears on the document you are working from, including its separators. Then choose how that string should be read:

• Auto-detect is the right default when you are reading someone else's data. It reports a single day when only one reading is possible and raises an explicit ambiguity warning when more than one is.
• An explicit format is the right choice when you already know the source. Pick the order that describes the string in front of you, not the order you want back.

Press Convert. The result panel restates the day in words, then lists ISO calendar, US, day-first, year-first, ordinal and week-date renderings, the weekday, the day-of-year number, the days remaining in the year, and the Unix timestamp at UTC midnight. Reset clears the field and the result. Separators are interchangeable, so 04.07.2026, 04/07/2026 and 04-07-2026 are all accepted as long as the same separator is used twice. The conversion runs entirely in the browser and the entered date is never uploaded.

The field-order formula, ordinal day, and ISO week number

Date-format conversion is a reordering operation on three integers. The converter splits the entry on its separator, assigns the pieces to year, month and day according to the selected format, and then validates the triple against the real length of that month in that year rather than against a fixed 31-day maximum. That is what rejects 2024-02-30 instead of silently rolling it forward to 1 March, which is what naive JavaScript date construction does.

Two-digit years are expanded with the POSIX century window: a value from 69 to 99 becomes 1969 to 1999, and a value from 00 to 68 becomes 2000 to 2068. The converter always tells you which century it applied, because that choice comes from a convention rather than from the digits themselves.

The Unix value reported for the converted day is the number of milliseconds from 00:00:00 UTC on 1 January 1970 to 00:00:00 UTC on that day. Using UTC midnight rather than local midnight makes the number reproducible: two people in different time zones converting the same calendar date get the same integer. One whole day contains exactly 86,400,000 milliseconds:

Divide the displayed millisecond value by 1000 for POSIX seconds. The day-of-year output counts days into the year: 1 January is 1, and the final day is 365, or 366 in a leap year. The converter derives it from the whole-day difference between the UTC representation of the selected date and 31 December of the previous year:

In this calculation, t is the UTC timestamp constructed from the converted year, month, and day, while t₀ is the UTC timestamp for 31 December of the preceding year. Using UTC calendar midnights prevents a daylight-saving transition from shifting the elapsed local time by an hour and corrupting the day count. Leap years are handled by the calendar arithmetic itself: 1 March is day 61 in a leap year and day 60 otherwise.

The ISO week number follows from the ordinal day and the ISO weekday number d, where Monday is 1 and Sunday is 7. Because ISO 8601 defines week 1 as the week containing 4 January, the week number is:

When that expression yields 0, the day belongs to the last week of the previous week-numbering year; when it yields 53 in a year that has only 52 ISO weeks, the day belongs to week 1 of the next one. The converter resolves both boundary cases before printing the week date, which is why the year shown in a week date is occasionally not the calendar year.

Worked example: converting 03/04/2026 in both directions

Enter 03/04/2026 with auto-detect selected. Both a month-first and a day-first reading produce real days — 3 April 2026 and 4 March 2026 — so the converter refuses to choose and reports the ambiguity, listing both candidates. That is the correct answer: the string alone does not identify a day.

Now choose US month-first. The fields become month 3, day 4, year 2026, giving 2026-03-04 in ISO, 03/04/2026 in US notation and 04/03/2026 day-first. March 2026 is preceded by 31 days in January and 28 in February, so the ordinal day is 31 + 28 + 4 = 63 and the ordinal date is 2026-063. That day is a Wednesday, ISO weekday 3, so the week number is the floor of (63 − 3 + 10) ÷ 7 = 10, giving the week date 2026-W10-3. The Unix value is 1772582400000 ms, or 1772582400 s, at UTC midnight.

Switch to day-first and the same digits become 3 April 2026: ISO 2026-04-03, ordinal day 31 + 28 + 31 + 3 = 93, week date 2026-W14-5, and a Unix value of 1775174400000 ms. The two readings sit 30 days apart, which is exactly the size of the error an unlabelled numeric date can introduce into a contract, a shipment or a medication schedule.

Contrast that with 25/04/2026. A month-first reading would need a 25th month, so it is discarded, one reading survives, and auto-detect resolves the string to 25 April 2026 without asking anything. A day number above 12 is the cheapest disambiguating signal there is.

Ambiguity Desk: the date-routing game on this page

The interactive Ambiguity Desk below turns those rules into a sorting task. Documents arrive at an international mail desk with a date stamped on them and, sometimes, a contextual clue: a postmark, a locale tag such as en-GB, or an invoice total in a particular currency. Your job is to route each document to the correct month on the calendar wall — or, when nothing in the document settles the field order, to the needs clarification tray.

The game shares the converter's parsing rules, so a document is treated as ambiguous by exactly the same test the auto-detect mode uses. Later shifts introduce ISO calendar, ordinal and week-date stamps, two-digit years subject to the century window, and a shrinking per-document clock. Filing a genuinely ambiguous document into a month slot is the mistake the desk punishes hardest, because it is the mistake that quietly corrupts real data.

Limitations and calendar assumptions of this date converter

• It converts a calendar date only. Times, time zones, and ISO date-time strings such as YYYY-MM-DDThh:mm:ss are outside its input scope. The Unix value shown corresponds to UTC midnight on the converted day.
• It reads numeric fields, not month names. 4 July 2026, Jul-04-26 and other written forms are not parsed; convert them by hand into one of the supported numeric layouts first.
• The two-digit-year century window is a convention, not information. A stamp reading 68 is expanded to 2068 and 69 to 1969, which will be wrong for genuinely historical documents. Prefer four-digit years whenever you control the source.
• It assumes the proleptic Gregorian calendar throughout. Dates before a country's Gregorian changeover, and non-Gregorian calendars, are not adjusted.
• Years are limited to the range 1 to 9999, matching the range ISO 8601 covers without an agreed expanded-year prefix.
• The entered value must identify a real calendar day. The converter rejects impossible dates instead of inferring an intended one, and it never reports a single day when more than one reading survives.

Frequently asked questions about converting ISO, US, and European dates

Sources: Field order, ordinal dates and week dates follow ISO 8601-1:2019, Date and time — Representations for information interchange, summarised for the web in the W3C date and time formats note and profiled for the internet by RFC 3339. The two-digit-year century window is the one specified for %y in POSIX strptime (IEEE Std 1003.1-2017), and the epoch is the POSIX Seconds Since the Epoch definition. Locale-by-locale field order is catalogued by the Unicode CLDR project.