ISO 8601 is the international standard for writing dates and times as text, ordered from largest unit to smallest, such as 2024-01-05 or 2024-01-05T14:30:00Z. It is widely used in APIs, JSON payloads and databases to avoid ambiguity between formats like dd/mm/yyyy and mm/dd/yyyy.
Why it matters: JSON has no native date type, so dates travel as strings and parsing depends on the library at each end. ISO 8601 gives teams a shared format, but it allows several variants. A system that accepts one variant and rejects another, or quietly drops the timezone, can produce bugs that only appear in production data.
In practice: Teams agree which ISO 8601 form they send and accept, including whether an offset is required. Testers try the basic form without separators, the extended form, a Z suffix, an explicit +00:00 offset and no offset at all. They also check that timezone information survives serialisation and that edge values far in the past or future are handled.
Examples:
- One service sends 2024-01-05 while another expects 20240105, and the import fails silently.
- A timestamp ending in Z is parsed correctly, but the same instant written with +00:00 is rejected.
- A value with no offset is treated as server local time, shifting records by several hours after a migration.
Common pitfalls:
- Assuming every ISO 8601 string is interchangeable, when libraries differ in which variants they accept.
- Stripping timezone information during serialisation, so the original instant can never be recovered.
Is ISO 8601 the same as UTC? No. ISO 8601 is a format for writing dates and times, while UTC is a time standard; an ISO 8601 timestamp can carry a UTC marker (Z), another offset, or no offset at all.
