ISO 8601
What the standard actually allows — and why that breadth bites interoperability.
ISO 8601 is an international standard for representing dates, times, and related
concepts as strings. Its scope is much wider than most developers realize:
beyond familiar 2026-06-05T14:30:00+02:00, it also defines ordinal dates
(2026-156), week dates (2026-W23-5), durations (P1Y2M10DT2H30M), and time
intervals — each in both “extended” (separator) and “basic” (no-separator,
20260605) forms.
Dates can also be given at reduced precision: just a year (2026), a
year-month (2026-06), or — in the classic (2004) forms — even a bare century
(20, meaning the 2000s). And by mutual agreement between sender and receiver,
an expanded representation prefixes the year with a sign and extra digits
(+002026), so years outside the ordinary 0000–9999 range can be written.
The standard also permits decimal fractions on the lowest-order time component
using either a comma or a period (14:30:00,5 or 14:30:00.5), and the T
date-time separator is optional in some contexts. Offsets may be expressed as
+02, +02:00, or +0200. All of this is valid ISO 8601.
When developers say “ISO format” colloquially, they almost always mean a narrow
subset: extended calendar date, T separator, milliseconds with a dot, and Z
or ±hh:mm offset. Relying on full ISO 8601 flexibility in a parser — or
assuming another system will produce that narrow form — is a common source of
interoperability bugs. Note that the complete ISO 8601 specification is a paid
ISO document; most implementations are written against secondary sources.
Format breadth
ISO 8601 defines more date and time representations than any single application needs. The practical consequence is that two strings can both be valid ISO 8601 while being unrecognizable to each other’s parser.
Pitfall: Passing an ISO 8601 basic-format timestamp (20260605T143000Z) to
a parser that only accepts extended format (2026-06-05T14:30:00Z) will fail
silently or raise a cryptic error — even though both strings are standards-conformant.
Go deeper: basic vs extended format and library gotchas
The extended format inserts hyphens between date components and colons between
time components (2026-06-05T14:30:00Z). The basic format omits those
separators (20260605T143000Z). ISO 8601 allows either; most internet-facing
systems and APIs expect extended format exclusively.
Week dates (2026-W23-5 = the fifth day of week 23 of 2026) and ordinal dates
(2026-156 = the 156th day of 2026) are equally valid ISO 8601 but are parsed
by almost no general-purpose date library by default. If you receive data from
a system (e.g. certain SAP/EDI pipelines) that emits week dates, verify your
parser handles them before assuming.
For internet and API interchange, RFC 3339 is the
well-defined profile to reach for. The two standards overlap heavily, but —
despite the common shorthand that “RFC 3339 is a subset of ISO 8601” — neither
is a strict superset of the other: each permits a few forms the other forbids
(ISO 8601 has week/ordinal dates and basic format; RFC 3339 allows a space
separator and the -00:00 “unknown offset”). ijmacd’s RFC 3339 vs ISO 8601
Venn diagram maps the overlap
example by example. For parsing arbitrary date-like input from users, see
Parsing user input.