ISO 8601 Date and Time Format Explained
ISO 8601 is the international standard for representing dates and times as strings. Its canonical form — 2024-03-15T14:30:00Z — is unambiguous, sortable, and supported in every modern language and database. This guide covers the format component by component, the RFC 3339 subset most APIs actually use, the newer RFC 9557 timezone extension, and the variants for durations, intervals, and week dates.
What is ISO 8601?
ISO 8601 is the International Organization for Standardization’s representation of dates and times. The current version (ISO 8601-1:2019 / -2:2019) defines a compact, ordered, language-neutral text format. Its whole purpose is to remove ambiguity: a date like 03/04/2024 is March 4th in the US and April 3rd in most of Europe, but 2024-03-04 means the same thing everywhere. The standard is also the basis for RFC 3339, the profile actually used by most internet protocols.
- Year-month-day order, always: 2024-03-15 (not 03/15/2024 or 15/03/2024)
- Time portion separated by a literal T or a space: 2024-03-15T14:30:00
- Timezone explicit: Z for UTC, or ±HH:MM for an offset
- Sortable as text — lexicographic order matches chronological order
The canonical date-time format
The most common form looks like 2024-03-15T14:30:00.123Z. Every component is fixed-width and zero-padded, which is what makes the format sortable and unambiguous.
| Component | Example | Meaning |
|---|---|---|
| YYYY | 2024 | Four-digit year |
| MM | 03 | Two-digit month (01–12) |
| DD | 15 | Two-digit day (01–31) |
| T | T | Date/time separator (RFC 3339 also allows a space) |
| hh:mm:ss | 14:30:00 | 24-hour time, zero-padded |
| .fff | .123 | Optional fractional seconds (any precision in ISO 8601) |
| Z or ±hh:mm | Z | Timezone designator (Z = UTC = +00:00) |
Timezone designators
ISO 8601 timezones are encoded as offsets from UTC, never as zone abbreviations like EST or CET (which are ambiguous). The string carries enough information to reconstruct the exact UTC instant, including the half-hour and 45-minute offsets some regions use.
| Designator | Offset from UTC | Example zone |
|---|---|---|
| Z | +00:00 | UTC ("Zulu" time) |
| +09:00 | 9 hours ahead | Japan Standard Time |
| -05:00 | 5 hours behind | US Eastern Standard Time |
| +05:30 | 5.5 hours ahead | India Standard Time |
| +05:45 | 5.75 hours ahead | Nepal Standard Time |
| (none) | unspecified | Local time — ambiguous; avoid in APIs |
ISO 8601 vs RFC 3339
RFC 3339 is a profile of ISO 8601 — more restrictive and easier to parse. Most internet protocols (JSON APIs, HTTP, IETF specs) target RFC 3339 specifically, so when an API says "ISO 8601" it almost always means the RFC 3339 subset. The differences are small but they decide whether a given string parses.
| Feature | ISO 8601 | RFC 3339 |
|---|---|---|
| Date/time separator | T, or omitted in basic format | T or a single space (required) |
| Timezone offset | Optional | Required |
| Fractional seconds | Arbitrary precision | Allowed, parser-capped |
| Basic format (no hyphens) | 20240315T143000Z allowed | Not allowed |
| Week / ordinal dates | Allowed | Not allowed |
| Typical use | Archives, spreadsheets, interchange | JSON APIs, HTTP, IETF specs |
RFC 9557: timezones and the Temporal extension
A plain offset like +01:00 tells you the instant but not the timezone — and offsets change with daylight saving, so the same zone is +01:00 in winter and +02:00 in summer. RFC 9557 (2024) closes that gap with the Internet Extended Date/Time Format (IXDTF): it appends the IANA zone name in brackets, as in 2024-03-15T14:30:00+01:00[Europe/Paris]. This is the string format the JavaScript Temporal API reads and writes, so you will see it more as Temporal adoption grows. It stays backward compatible — strip the bracketed suffix and you have an ordinary RFC 3339 timestamp.
- Offset only: 2024-03-15T14:30:00+01:00 — the instant, but not the zone
- IXDTF (RFC 9557): 2024-03-15T14:30:00+01:00[Europe/Paris] — instant plus zone
- Backward compatible: the bracketed tag is ignorable by RFC 3339 parsers
Variants: durations, intervals, week dates
ISO 8601 covers more than instants. Several variants come up regularly in scheduling, archiving, and reporting systems:
- Durations: P3Y6M4DT12H30M5S = 3 years, 6 months, 4 days, 12 hours, 30 minutes, 5 seconds
- Intervals: 2024-01-01/2024-02-01, or 2024-01-01/P1M (start + duration)
- Ordinal dates: 2024-075 = the 75th day of 2024 (March 15)
- Week dates: 2024-W11-5 = Friday of ISO week 11 of 2024
- Repeating intervals: R3/2024-01-01/P1D = three one-day intervals starting Jan 1
ISO 8601 in code
Every mainstream language can produce and parse the RFC 3339 subset out of the box. The safest habit is to emit UTC with a Z and parse back to an instant, leaving any timezone conversion for the display layer.
- JavaScript emit: new Date().toISOString() // '2024-03-15T14:30:00.123Z'
- JavaScript parse: new Date('2024-03-15T14:30:00Z') // RFC 3339 subset
- Python emit: datetime.now(timezone.utc).isoformat()
- Python parse: datetime.fromisoformat('2024-03-15T14:30:00+00:00') // full ISO in 3.11+
- Most databases (Postgres, SQLite) accept and return ISO 8601 timestamptz directly
Common ISO 8601 mistakes
Even with a strict standard, parsing and emitting code makes the same handful of errors:
- Dropping the timezone: 2024-03-15T14:30:00 with no Z or offset is ambiguous
- Using "+0000" instead of "+00:00" — some parsers accept it, RFC 3339 does not
- Using a non-letter T (Unicode lookalikes copy-paste poorly)
- Mixing 12-hour AM/PM into ISO 8601 — it is always 24-hour
- Truncating fractional seconds without rounding — pick a precision and stick to it
- Treating ISO 8601 as locale-aware — it is not; the format is fixed regardless of language
Related references
FAQ
- Is "2024-03-15 14:30:00Z" valid ISO 8601?
- Yes — the space between date and time is allowed in ISO 8601 (and in RFC 3339). The T form is preferred for unambiguous machine parsing.
- What does the Z at the end mean?
- Z means UTC (offset +00:00). It is short for "Zulu time", the NATO/aviation phonetic for the letter Z.
- How do I parse ISO 8601 in JavaScript?
- new Date("2024-03-15T14:30:00Z") works for the standard RFC 3339 subset. For broader ISO 8601 support, use a library like date-fns or the Temporal API.
- Is ISO 8601 the same as RFC 3339?
- No — RFC 3339 is a strict subset. Every RFC 3339 timestamp is valid ISO 8601, but not every ISO 8601 timestamp is valid RFC 3339.
- What is RFC 9557?
- RFC 9557 (2024) extends RFC 3339 with the Internet Extended Date/Time Format (IXDTF). It adds a bracketed IANA timezone suffix — for example 2024-03-15T14:30:00+01:00[Europe/Paris] — and underpins the string format used by the JavaScript Temporal API.
- Is the T separator required?
- In strict ISO 8601 the T can be dropped in the basic format; RFC 3339 requires a T or a single space. For machine parsing, always include the T.
- What is the difference between ISO 8601 and ISO 8601-2?
- ISO 8601-1 covers basic date and time representation. ISO 8601-2 (the 2019 extension) adds new constructs like uncertain dates, qualifying values, and complex intervals.