Date Format Table
| Region | Order | Written form | 4 March 2026 as |
|---|---|---|---|
| United States | MDY | 03/04/2026 | March 4 |
| UK, Ireland | DMY | 04/03/2026 | March 4 |
| Germany, France, most of Europe | DMY | 04.03.2026 | March 4 |
| China, Japan, Korea | YMD | 2026/03/04 | March 4 |
| ISO 8601 (international) | YMD | 2026-03-04 | unambiguous everywhere |
| Aviation, military | DDMMMYY | 04MAR26 | month spelled, no slashes |
The same six digits - 03/04/2026 - mean March 4 in New York and April 3 in London, and neither writer is wrong: the US inherited month-first from its newspapers, most of the world writes smallest-unit-first, and East Asia writes biggest-first. The table maps the orders region by region, with one written example that makes the split visible.
Bottom line: the danger zone is days 1-12. Whenever both the month and the day are twelve or below, MDY and DMY both produce plausible dates that silently disagree - 144 combinations a year of pure ambiguity between the US and Europe. Everything else (13th through 31st) self-identifies, which is why '04MAR26' with a spelled month became the aviation and military standard.
The honest part: there is no world police for date formats - ISO 8601 (2026-03-04) is a voluntary standard that wins because it sorts correctly as plain text and reads the same everywhere, not because anyone must follow it. Spreadsheets are the usual traitor: they auto-convert anything date-shaped, and a US-authored export re-parses into different dates on a European locale.
How to use
- Find your reader's region in the table before writing a date for them - the order column is the whole story.
- Crossing borders in a form or dataset? Switch to ISO 8601 (2026-03-04) or spell the month (04 Mar 2026); both survive every locale.
- Debugging a spreadsheet date that shifted? Check the source locale first - the number underneath may be right while the parse flipped month and day.
Frequently asked questions
What date format does the US use?
Month-day-year: 03/04/2026 means March 4. The order came through 20th-century newspapers and style guides ('April 3, 2026' reads naturally aloud), and it survives in forms, IDs and software defaults. The catch is export: a US-formatted 03/04/2026 opened on a European machine parses as April 3 - both sides see a valid date, which is what makes the bug silent.
Which countries use DD/MM/YYYY?
The UK, Ireland, most of Europe (with dots in Germany and Austria: 04.03.2026), Australia, New Zealand, India and most of South America and Africa - roughly the majority of countries. East Asia runs biggest-first: China, Japan and Korea write year-month-day, the same order as ISO 8601, which is no coincidence - the standard codified the order that already sorted correctly.
What is the 03/04 problem?
When the day is 12 or less, both MDY and DMY parse - so 12 days times 12 months gives 144 ambiguous combos a year between the US and day-first countries. The reliable fixes, in order of robustness: spell the month (04 Mar 2026 - unambiguous, human-readable), use ISO 8601 (2026-03-04 - sorts as text), or force a date picker in UI instead of a free text field.
Why does Excel change my dates?
Spreadsheets auto-convert anything date-shaped on open: type 03/04 in a US locale and it becomes March 4 (stored as a serial number); the same file on a UK locale re-parses to April 3. The stored serial is right - the display order just follows the local convention. The classic corruption is a CSV of ISO dates like 2026-03-04 getting 'helpfully' converted to a local format, or worse, month and day swapped on import.
Is ISO 8601 the international date format?
De jure it is a voluntary standard; de facto it is the interchange answer. Year-month-day with zero padding (2026-03-04) reads the same regardless of the reader's locale, sorts correctly as plain text in filenames, logs and databases, and survives spreadsheet round-trips better than any numeric alternative. Aviation's DDMMMYY (04MAR26) solves the same problem differently - by removing the slashes entirely.