ISO 8601 is the international standard for representing dates and times — the reason 2026-10-03 means October 3rd to everyone on Earth, regardless of whether their local convention reads 03/10 or 10/03. It kills the single most dangerous ambiguity in computing (is 03/04 March 4th or April 3rd?) by mandating one ordering: most significant first — year, month, day. But ISO 8601 is much bigger than the familiar YYYY-MM-DDThh:mm:ssZ shape most developers know. It also standardizes week dates, ordinal dates, durations, and time intervals — and its relationship to RFC 3339 trips up even experienced engineers.
Anatomy of a Date-Time String
The canonical form you see in APIs and databases:
2026-10-03T14:30:00+02:00
2026— year (four digits; expanded forms allow more)-10— month (01–12, always zero-padded)-03— day of monthT— the separator between date and time parts (required, not optional)14:30:00— local time, 24-hour clock; seconds may be omitted and fractional seconds appended after a comma or period+02:00— UTC offset;Zmeans +00:00 (UTC). No offset at all means local time with no timezone information — a common source of bugs.
The standard defines a basic format without separators (20261003T143000+0200) and the extended format above with hyphens and colons. In practice, extended format dominates because it's human-readable; APIs almost universally use it.
Three Ways to Write the Same Date
ISO 8601 actually standardizes three date representations. October 3, 2026 is:
- Calendar date:
2026-10-03— the familiar year-month-day. - Ordinal date:
2026-276— year plus day-of-year (1–366). Handy in logistics and day-counting domains where "day 276" is more natural than a month/day pair. - Week date:
2026-W40-6— ISO year, week number, weekday (1=Monday…7=Sunday). Week 1 is the week containing the year's first Thursday — which means2026-01-01can belong to week date2025-W53-4, and December 29–31 can fall in week 1 of the next year. This mismatch between calendar year and ISO week-year is a classic source of off-by-one bugs in reporting systems.
Test any of these against our ISO 8601 validator — it parses all three families plus durations and intervals, explains exactly which component fails when a string is invalid, and shows the normalized UTC form.
Durations: PnYnMnDTnHnMnS
Durations (lengths of time, not points in time) start with P for "period" and follow a strict positional pattern:
P1Y2M10DT2H30M
Read: 1 year, 2 months, 10 days, 2 hours, 30 minutes. The T separates the date components (Y, M, W, D) from the time components (H, M, S) — which is why M can mean month or minute depending on which side of T it appears on. That's the most common parsing mistake: P1M is one month, but PT1M is one minute. Weeks (P2W) can't be combined with other units. Valid examples: P3Y6M4DT12H30M5S, PT15M, P0.5Y (fractions allowed on the smallest unit only).
Time Intervals
Intervals are two endpoints joined by a slash — and one endpoint can be a duration:
2026-10-03T00:00:00Z/2026-10-04T00:00:00Z— start/end, the explicit form2026-10-03T00:00:00Z/P1DT12H— start plus durationP1DT12H/2026-10-04T00:00:00Z— duration before an end
Repeating intervals prefix an R: R5/2026-01-01T00:00:00Z/P1W means "every week, five times, starting January 1st." Recurrence rules like this power scheduling systems that need standard, unambiguous semantics.
Reduced Precision and Fractional Seconds
ISO 8601 allows dropping the least significant parts: 2026-10 is "October 2026," 2026 is the year — useful for "valid through" fields and partial dates in databases. Fractional seconds append after a comma or period — 14:30:00,5 or 14:30:00.500. Both separators are legal in the standard, though most implementations (and RFC 3339) prefer the period.
ISO 8601 vs RFC 3339: The Subset Everyone Actually Uses
RFC 3339 is the IETF's profile of ISO 8601 for internet protocols — a deliberately restricted subset. If you've written timestamps for JSON APIs, you were really writing RFC 3339. The differences that matter:
| Feature | ISO 8601 | RFC 3339 |
|---|---|---|
| Offset required | Optional (local time allowed) | Mandatory — Z or ±hh:mm |
| Basic format (no separators) | Yes — 20261003 | No — separators required |
| Week & ordinal dates | Yes — 2026-W40-6, 2026-276 | No — calendar dates only |
| Durations & intervals | Yes | No — not covered |
Reduced precision (2026-10) | Yes | No — full dates required |
| Space separator for T | No (T only) | Tolerated in practice (a NOTE permits it for readability) |
The practical rule: emit RFC 3339, accept ISO 8601. RFC 3339's mandatory offset kills the ambiguous-local-time bug class entirely, which is why it's the right choice for wire formats. But if you validate incoming user or partner data with an RFC 3339-only regex, you'll reject perfectly legal ISO 8601 inputs like week dates and durations.
Validation Gotchas That Break Real Systems
- Week 53 exists (sometimes).
2026-W53is invalid — 2026 has only 52 ISO weeks — but2020-W53is legal. Validators must compute the actual ISO week count per year. - Leap days and leap seconds.
2026-02-29is invalid (2026 isn't a leap year);23:59:60is technically legal for leap seconds and will crash parsers that assume seconds max at 59. 24:00vs00:00. ISO 8601 permits24:00meaning end-of-day; RFC 3339 and most implementations don't. Normalize it to00:00of the next day on ingest.Zvs missing offset.2026-10-03T14:30:00isn't UTC — it's unknown. Storing it as UTC silently shifts times by your server's timezone.- Year-week boundary. Formatting a week date with a calendar-year field produces strings like
2026-W01for December 2025 dates — the week-year differs from the calendar year. Always use the ISO week-year when formatting.
Test Your Strings
Our free ISO 8601 / RFC 3339 validator handles bulk validation of all the formats above — calendar, ordinal, and week dates; full date-times with offsets; durations; and intervals — with per-line explanations of which component failed and a UTC canonical form for valid inputs. Everything runs in your browser; nothing is uploaded.
Working with other structured formats? Our HL7 parser decodes healthcare messages (which use their own timestamp quirks), and the HL7 v2 structure guide shows how standards bodies solve similar problems.
Frequently Asked Questions
What does the T in ISO 8601 mean?
It's just a separator marking the transition from the date part to the time part — 2026-10-03T14:30:00 reads "October 3, 2026, at 14:30:00." It's required in ISO 8601 (not a placeholder). In durations, a second T also separates date units (years/months/days) from time units (hours/minutes/seconds) — which is how P1M (one month) differs from PT1M (one minute).
Is RFC 3339 the same as ISO 8601?
No — RFC 3339 is a profile (strict subset) of ISO 8601 designed for internet protocols. It mandates a UTC offset, requires separators, and only allows calendar dates — no week dates, ordinal dates, durations, intervals, or reduced precision. A valid RFC 3339 timestamp is always valid ISO 8601, but the reverse is not true.
What is an ISO week date?
A date expressed as year-weeknumber-weekday: 2026-W40-6 is Saturday of week 40 (October 3, 2026). Week 1 is the week containing the first Thursday of the year, and weeks run Monday–Sunday. This means the ISO week-year can differ from the calendar year at year boundaries — 2025-12-29 through 2025-12-31 can belong to 2026-W01.
How do I write a duration in ISO 8601?
Start with P, then date components, then T, then time components: P1Y2M10DT2H30M = 1 year, 2 months, 10 days, 2 hours, 30 minutes. Omit components you don't need (PT15M = 15 minutes). Weeks use W and can't be mixed with other units.
Is 24:00 a valid ISO 8601 time?
Yes — ISO 8601 accepts 24:00 to mean midnight at the end of the day, equivalent to 00:00 of the following day. But RFC 3339 and most parsers reject it, so normalize to 00:00 when exchanging data.
