ISO 8601

ISO 8601 is the international standard for representing dates and times as text. Published by the International Organization for Standardization in 1988 and revised periodically since. The canonical form for a full timestamp is:

YYYY-MM-DDTHH:MM:SSZ

— for example, 2026-05-14T14:30:00Z. The T separates the date and time portions; the Z indicates UTC (Zulu time, in military nomenclature). For zones other than UTC, the suffix is the signed offset: +03:00 for Istanbul, -05:00 for US Eastern in winter.

Why ISO 8601 won the format war:

• Unambiguous.Most other date formats collide. “01/02/2026” means January 2nd in the US and February 1st almost everywhere else. ISO 8601 has one parsing.
• Sortable as a string. Lexicographic order equals chronological order. 2026-05-14 sorts after 2026-05-13 by simple text comparison.
• Locale-independent. Independent of which month-name language the reader uses.
• Year-first means trivially extractable. Need just the date from a timestamp? Take the first 10 characters.

Modern programming languages and APIs default to ISO 8601. JavaScript’s Date.prototype.toISOString() emits ISO 8601. JSON has no native date type; ISO 8601 is the unspoken convention. PostgreSQL, MySQL, MongoDB, and SQLite all accept ISO 8601 strings as date inputs.

RFC 3339 is a stricter subset of ISO 8601 used by Internet protocols. The difference is small — RFC 3339 requires the T separator (ISO 8601 allows a space) and requires a timezone offset (ISO 8601 allows omitting it). For all practical purposes treat them as the same standard.

Week-numbering and ordinal-date forms — the lesser-known ISO 8601 modes: the standard also defines a week-of-year format (2026-W21-5means “Friday of ISO week 21, 2026”) and an ordinal-date format (2026-141means “the 141st day of 2026”). ISO weeks always start on Monday, and week 1 is the week containing the first Thursday of the year — which sometimes puts late-December dates into the next year’s week 1 (e.g. 2025-12-29 is in 2026-W01). Most calendar software respects this convention for week-numbered views; databases with date functions (Postgres EXTRACT(week FROM ...), MySQL WEEK()) expose ISO and non-ISO week modes — picking the wrong one is a common reporting bug.

Permissive vs strict parsing — the JavaScript trap: new Date("2026-05-14")parses as UTC midnight (because date-only ISO strings are spec’d as UTC). new Date("2026-05-14T00:00:00")without a timezone parses as local midnight (the spec switched in ES2016 — it used to be UTC). The same string can produce different timestamps in different browsers if engines disagree on which spec version they implement. Always include an explicit Z or offset in stored ISO 8601 strings to avoid this. Reference: ISO 8601:2019 — Date and time representations, RFC 3339.