Date formats by country, DMY, MDY, YMD, and the standards that defined them

The 3 great date format families

Every civil date format in current use belongs to one of three families, and the family is determined by which unit comes first: day, month, or year. The split is close to universal in human writing and is the source of more cross-border software bugs than any other format question. "DMY" is short for day-month-year, "MDY" for month-day-year, and "YMD" for year-month-day. Every country picks a primary, almost every country also accepts ISO 8601 (the YMD form with hyphens), and the order they actually print on a banking form or a train ticket is the one that matters.

DMY is the dominant civil form across roughly two-thirds of the world by population. It covers the United Kingdom, Ireland, almost all of continental Europe, India, Pakistan, Bangladesh, most of Africa, all of South America, Australia, and New Zealand. The order matches the spoken phrasing of most European and Indo-Aryan languages: "14 March 2026" reads as "the fourteenth of March, 2026". National standards bodies including BSI (BS 7666 in the UK), DIN (DIN 5008 in Germany), AFNOR (NF Z 12-006 in France), and BIS (IS 7900 in India) all codify a DMY civil form alongside the technical ISO 8601 YMD.

MDY is overwhelmingly dominated by one country: the United States. Belize and the Federated States of Micronesia are the only other countries with a clearly MDY-first civil convention; the Philippines uses MDY in retail and government but DMY in much informal writing, an artifact of layered colonial influence. The US convention is codified by ANSI X3.30 (originally from 1971, withdrawn but never replaced) and used on every USPS form, every IRS form, and most consumer software that defaults to en-US.

YMD is the family that ISO 8601 picked for the international wire format, and it is the native civil form in East Asia and a few outliers. Japan (JIS Z 8301), South Korea (KS X ISO 8601), China (GB/T 7408), Mongolia (MNS ISO 8601), and Taiwan (CNS 7648) all specify YMD as the primary civil format, typically with hyphens, slashes, or in Japan and Korea the locale-specific 年月日 characters. Outside East Asia, YMD is the native form in Hungary (the only European language to do this), Lithuania, Iran (in the Persian Jalali calendar), Nepal (in the Bikram Sambat calendar), and South Africa under SANS ISO 8601. Everywhere else, YMD with hyphens shows up as the technical or machine-readable format alongside the local civil form.

The choice is not arbitrary. Each family preserves a particular sortability property: DMY sorts naturally by day within a fixed month, MDY sorts naturally by month within a fixed year, and YMD is the only family that sorts lexicographically as a string into chronological order. That last property, sortable as a string, is why the international standard picked it.

Why the US uses MDY

The simple answer is "because the British did it that way in 1700", and the answer is mostly correct. Eighteenth-century English correspondence routinely wrote "March the fourteenth, 1776" in body text, with the spoken month-first order preserved in writing alongside the older legal day-first form ("the fourteenth day of March"). Both conventions crossed the Atlantic with English settlers. Over the 19th century, British civil usage drifted toward the day-first form for everyday writing, the order that matched the new Royal Mail's preferred sorting, while American usage kept the month-first form that appeared in the Declaration of Independence ("July 4, 1776") and most of the founding documents.

By the late 19th century the two conventions were entrenched and self-reinforcing. The US Post Office Department standardized on month-first dates for postmarks and internal forms; school curricula in both countries codified the local form; handwriting templates and typing manuals followed; and by the mid-20th century the Department of Defense had specified MDY for all military documents. ANSI X3.30 in 1971 codified the federal civil practice, MM/DD/YYYY with optional zero-padding, and that standard, even though it was formally withdrawn in 2008 without replacement, is still what every USPS form, IRS form, and DMV application uses today.

The strange wrinkle is the one date Americans say in DMY order: the Fourth of July. The holiday name predates the standardization, so colloquial speech preserved the older British form for that one calendar day. Independence Day is "the Fourth of July" or "July Fourth", both are normal, the first is DMY, the second is MDY, and the country managed to standardize on MDY for everything else without breaking the holiday name. It is the small linguistic fossil that reveals where the divergence came from.

MDY is not without function. The format sorts naturally by month within a fixed year, which is genuinely useful for fiscal calendars, school years, and any context where you scan a list of dates within one year and the month is the meaningful axis. In US business reporting, where the fiscal year is anchored on January 1 (or, less commonly, October 1), the month-first order means a column of dates reads month-major at a glance. The same property is why the US military, which thinks in deployment-month rather than calendar-day, still uses it.

Why ISO 8601 (YMD with dashes) won the digital age

When the International Organization for Standardization sat down to pick an international date format in the 1980s, they could have picked any of the three families. The committee picked YMD with hyphens- 2026-03-14, and the choice has held up against forty years of pressure to change it. ISO 8601 was first published in 1988, revised in 2000, 2004, and most recently as ISO 8601-1:2019 and ISO 8601-2:2019. Its YMD form is now the native wire format of essentially every API, database, and operating system in production use.

Three properties made YMD the right choice for machine-readable use, and all three were on the table from the start:

• Sortable as a string. Because the longest unit (year) appears first and each subsequent unit is fixed-width with leading zeros, 2025-12-31 sorts before 2026-01-01 with a plain string comparison. No date parsing required, no locale dependency, no special collation rules. This single property is why YYYY-MM-DD shows up in filenames, log timestamps, and primary keys all over modern systems. The DMY and MDY families cannot do this.
• Disambiguates 01/02/03. A three-part date with a 2-digit year is the locale war in compressed form: a US reader sees Jan 2, 2003, a UK reader sees Feb 1, 2003, and either reading is wrong by 11 months from the other. ISO 8601 uses 4-digit years and a hyphen separator that almost no civil format uses, so an ISO string is unambiguous on sight, and a strict parser will reject anything else.
• Required by every modern spec. RFC 3339 (the strict subset of ISO 8601 used by JSON APIs, OpenAPI, JSON Schema, OpenTelemetry, CloudEvents, and every public web API of consequence) mandates the YMD form with hyphens and a timezone designator. SQL TIMESTAMP WITH TIME ZONE stores instants that render as YMD. ECMA-402 (the JavaScript Intl spec) uses ISO 8601 as the internal exchange format. There is no modern technical context where the format is contested.

ISO 8601 also defines optional extras, week dates (2026-W11-6), ordinal dates (2026-073), durations (P3Y6M4DT12H30M5S), intervals, and recurring intervals, but the calendar-date form is the one that runs the digital world. The full developer reference, including the differences between ISO 8601 and the stricter RFC 3339 subset, lives in the date and time format style guide.

What ISO 8601 did not do is dislodge the civil DMY and MDY conventions. People still write 14/03/2026 on UK bank cheques and 3/14/2026 on US tax forms. National standards bodies almost universally adopt ISO 8601 as their technical standard while leaving the civil convention untouched, which is the right outcome. DIN 5008 (Germany) explicitly says: use ISO 8601 in correspondence; DMY with full stops is acceptable in informal contexts. BS 7666 (UK) and AS ISO 8601 (Australia) say the same. Civil writing and machine writing are different jobs.

The country table

All 101 countries currently tracked by ClockOrbit, with primary civil date format, other accepted forms, common separator, an example for 14 March 2026 in the country's primary format, and the standards body or source that defines it. "CLDR" in the source column means the convention is not codified by a national standards body and the row reflects the Unicode Common Locale Data Repository's observed-usage defaults.

Sorted by region, then alphabetically by country name. Where a country has multiple official languages with different conventions (Switzerland, Belgium, Canada), the row reflects the most common civil form; the alternatives are noted in the "Other accepted" column.

A few patterns are worth calling out. ISO 8601 has been adopted as a national standard in essentially every country with a national standards body, DIN ISO 8601, BS EN 28601, NF EN 28601, JIS Z 8301 with ISO 8601 alignment, GB/T 7408, KS X ISO 8601, AS ISO 8601, GOST ISO 8601, and so on. The standards documents are typically identical to ISO 8601-1:2019 with a national cover page; the bodies adopt the standard so that ISO 8601 is the legally recognised technical format inside the country.

The non-Gregorian calendars in the "Other accepted" column are worth a note: Saudi Arabia (Hijri AH), Iran (Persian Jalali), Israel (Hebrew), Thailand (Buddhist Era), Taiwan (Republic of China year, currently 115 for the year that overlaps Gregorian 2026), Ethiopia (Ge'ez), Nepal (Bikram Sambat, currently 2082-2083), and Japan (Reiwa era, currently R8 for 2026) all have parallel civil calendars in active use. Their structural rules are covered in the per-calendar pages, the Hijri converter, Persian calendar, and Japanese wareki converter are the relevant tools. The row here reflects the Gregorian civil format the country uses in international and digital contexts.

Common ambiguity disasters

The format split is the single largest source of cross-border date bugs. When a date string travels between systems that interpret the unit order differently, it arrives meaning something else than it left meaning. The string is well-formed in both, the parsers do not error, and the data is wrong by a number of days that depends on the specific values.

// 01/02/03, three valid interpretations, no way to tell from the string:
"01/02/03" in en-US locale  → Jan 2, 2003   (MDY)
"01/02/03" in en-GB locale  → Feb 1, 2003   (DMY)
"01/02/03" parsed as ISO    → Jan 2, 2003   (YMD, 2-digit year)
"01/02/03" parsed as ISO    → Feb 3, 2001   (YMD, alternative grouping)

// Same problem with 4-digit years on the boundary:
"03/04/2026" in en-US       → March 4, 2026
"03/04/2026" in en-GB       → April 3, 2026

// And the famous Excel pasteboard surprise:
"1-3" auto-coerces to       → 1 March (current year)   in en-GB Excel
"1-3" auto-coerces to       → January 3 (current year) in en-US Excel

The API gotcha. A REST or GraphQL endpoint that accepts a date field as a plain string without specifying the format is a bug factory. The client serializes whatever its locale produces; the server parses whatever its locale expects; they disagree any time the day-of-month is less than or equal to 12. Roughly 40% of all dates fall into this danger zone. The fix is to spec the format explicitly as ISO 8601 (RFC 3339) in the API contract and reject anything else at the validator. OpenAPI format: date already does this; using it catches the bug at the schema level.

Banking and airline gotchas. Both industries have a long history of real legal disputes traceable to MDY-versus-DMY mixing on customer-facing forms. The most-cited cases involve travel insurance claims where the "date of incident" field on the US-hosted website was filled by a UK traveller using DMY, the back-office system parsed it as MDY, the parsed date fell outside the policy coverage window, and the claim was denied for a reason that did not exist. Most large carriers and banks now use date-picker components that emit ISO 8601 regardless of locale, partly for this reason. The user-facing display is locale-aware; the transmitted value is not.

The developer gotcha. Never store a date as a string in a country-specific format like "14/03/2026" or "03/14/2026". The string carries no information about which locale produced it, the locale of the next reader is not guaranteed to match, and the conversion is impossible to do retroactively for ambiguous values. Use a date type (SQL DATE, ISO 8601 string, or epoch integer) at the storage layer and format only at the rendering boundary.

Spreadsheet auto-coercion. Excel and Google Sheets both eagerly parse two-part strings like 1-3 or 3/4 as dates in the user's locale. The same CSV file opened in en-US Excel and en-GB Excel can contain genuinely different data after Excel auto-saves it. The defensive pattern is to prefix any date-like cell with an apostrophe ('14/03/2026), forcing Excel to treat it as text. The robust pattern is to store dates as ISO 8601 strings in the source CSV, Excel still parses them, but unambiguously.

Two-digit years. The Y2K problem is a quarter century old and the two-digit year is still ubiquitous on bank statements, IRS forms, and any legacy data feed. Each language picks a different century-inference cutoff: Python's strptime with %y uses 1969 as the breakpoint (00-68 → 2000s, 69-99 → 1900s), Java's SimpleDateFormat uses 80 years relative to "now", .NET uses the locale calendar's TwoDigitYearMax. If you have to parse a 2-digit year, normalize to four digits at the boundary and store the four-digit form. If you can avoid it, reject the input.

What to do in code

The pattern that survives every locale war, every cross-border data feed, and every future format change is the same one that survived the JSON-vs-XML wars and the UTF-8 transition: pick the lowest-ambiguity representation for the boundaries between systems, and convert to the local convention only at the boundary between the system and the human.

1. Store as ISO 8601

// Always store and transmit dates in ISO 8601 / RFC 3339.
//
// Database (Postgres):
CREATE TABLE invoices (
  id            bigserial PRIMARY KEY,
  invoice_date  date NOT NULL,                  -- YYYY-MM-DD on disk
  due_at        timestamptz NOT NULL            -- UTC instant
);

// API payload (RFC 3339):
{
  "invoice_date": "2026-03-14",
  "due_at": "2026-04-13T23:59:59Z"
}

// Never store a localized string:
{ "invoice_date": "03/14/2026" }   // wrong: locale-dependent
{ "invoice_date": "14/03/2026" }   // wrong: locale-dependent
{ "invoice_date": "14.03.2026" }   // wrong: locale-dependent

The storage rule has no exceptions. SQL DATE for date-only values (the column stores YYYY-MM-DD on disk regardless of the syntax used on insert). SQL TIMESTAMP WITH TIME ZONE for instants (the column stores a UTC instant, rendered as ISO 8601 with a Z suffix on output). ISO 8601 strings in JSON payloads, in YAML config, in log files, in filenames, in URL slugs, everywhere. The format is locale-independent, sortable as a string, and parseable by every modern library.

2. Render with Intl.DateTimeFormat

// Render to the user's locale on display only.
// Intl.DateTimeFormat is the right primitive in the browser; CLDR-backed
// formatters do the same job server-side.

const stored = "2026-03-14";   // ISO 8601 from the database
const d = new Date(stored + "T00:00:00Z");

new Intl.DateTimeFormat("en-US", { dateStyle: "long" }).format(d);
// "March 14, 2026"

new Intl.DateTimeFormat("en-GB", { dateStyle: "long" }).format(d);
// "14 March 2026"

new Intl.DateTimeFormat("de-DE", { dateStyle: "long" }).format(d);
// "14. März 2026"

new Intl.DateTimeFormat("ja-JP", { dateStyle: "long" }).format(d);
// "2026年3月14日"

new Intl.DateTimeFormat("hu-HU", { dateStyle: "long" }).format(d);
// "2026. március 14."

// For dates persisted as Date objects already, pass them through.
// Never format on storage; format only at the rendering boundary.

Intl.DateTimeFormat is the right primitive in the browser. It uses CLDR locale data for the format, calendar system, numbering system, and weekday names, and it works correctly out of the box for every locale in CLDR, including the calendar-specific quirks like Japanese era display, Hebrew calendar months, and Hijri-civil leap year handling. On the server, the same job is done by ICU directly (in Python via babel or icu, in Java via java.text.MessageFormat with Locale, in Go via golang.org/x/text). Do not roll your own format string for civil display, the locale data is too large and changes too often.

3. Convert one-offs with the tool

For the conversions you do once at the command line or in the browser, the date format converter round-trips between ISO 8601, RFC 3339, epoch, common strftime patterns, and the major locale presets. The epoch converter handles second-, millisecond-, microsecond-, and nanosecond-precision epoch values in any IANA timezone. Both are zero-configuration and remember the last input you typed.

4. Validate at the boundary

When you accept a date from an upstream system you do not control, validate it as ISO 8601 at the boundary and reject anything else. OpenAPI format: date and JSON Schema format: date-time both enforce the RFC 3339 subset. In raw Python, the modern primitive is datetime.date.fromisoformat() (which raises ValueError on anything non-ISO). In JavaScript, the safest pattern is a regex pre-check followed by new Date(...), then a sanity check that isNaN(d.getTime()) is false. In Go, time.Parse(time.DateOnly, ...) or time.Parse(time.RFC3339, ...). The fail-fast pattern at the boundary stops a malformed date from quietly corrupting downstream computations.

Related guides on the same theme: the date and time format style guide covers the developer-side format choices in detail (RFC 3339 versus ISO 8601, SQL type selection, the year-2038 problem, anti-patterns). The time zones explained primer walks through the IANA tzdata layer that sits underneath every timezone-aware date computation. The JavaScript date and time reference is the language-specific guide for Node, browser, and Temporal.

FAQ