What is ISO 8601?

What does ISO 8601 actually specify?

ISO 8601 is a single standard, published in two parts, that fixes how a calendar date, a wall-clock time, an instant, a duration, an interval, and a recurring interval are written as strings using the Gregorian calendar. The two parts are ISO 8601-1:2019, which carries the rules everyone uses day-to-day, and ISO 8601-2:2019, which adds optional extensions for cases the basic rules cannot express — uncertain dates, dates beyond the four-digit year range, sets of dates, and similar.¹² Both parts came into force together in February 2019 and superseded the previous single-document edition, ISO 8601:2004.

The standard is normative for the strings, not for any particular language or machine encoding. It does not specify a wire format, a database column type, or a programming-language API. What it specifies is what an unambiguous, locale-neutral, machine-friendly date or time string looks like. Software that wants to interoperate across borders writes ISO 8601 strings on the outside and uses whatever it likes on the inside.

The standard text itself is paywalled. The shape of every form it defines is, however, public — published as worked grammar in IETF and W3C documents that explicitly profile ISO 8601 (RFC 3339, RFC 9557, the W3C Note on Date and Time Formats), reproduced in browser and language standards (the HTML Living Standard, ECMAScript), and built into every major operating system and database.³⁴⁵⁶

What does an ISO 8601 date or time look like?

The fundamental rule is that fields run from largest unit to smallest, separated by hyphens for dates and colons for times. A complete calendar date is year-month-day: 2026-05-09. A complete clock time is hour:minute:second: 14:30:00. A combined date and time joins the two with a literal capital T: 2026-05-09T14:30:00.¹

Because the units run from largest to smallest, an alphabetical sort of ISO 8601 strings is the same as a chronological sort. 2026-01-01 comes before 2026-12-31 in both ASCII order and time order. This is the property that makes the format ubiquitous in filenames, log files, and database keys, and it is the only common date format that has it.

The standard distinguishes between the extended format and the basic format. Extended is what every example so far has used: hyphens between date fields, colons between time fields. Basic format omits the separators — the same instant becomes 20260509T143000 — and is intended for environments that cannot accommodate punctuation. Extended format is what humans, internet protocols, and databases use almost universally; basic format mostly survives in narrow legacy contexts.¹

Several other date forms are also defined and occasionally seen in the wild:

• Ordinal date — year and day-of-year, separated by a single hyphen: 2026-129 means the 129th day of 2026 (which is 9 May 2026). Used in scientific data files and in agricultural and aviation contexts.¹
• Week date — year-week-weekday with a literal W in front of the week number: 2026-W19-6 means the 6th day (Saturday) of the 19th ISO week of 2026. ISO weeks start on Monday and week 1 is the week containing the first Thursday of the year, so the ISO week-numbering year sometimes differs from the calendar year by one day at the boundaries. The full mechanics are covered in the ISO week date concept page, and our week-number tool computes the week number for any date.¹
• Year-and-month — 2026-05. Permitted as a calendar date with day-precision omitted.¹

For the time component, the standard allows a fractional seconds field after a comma or a period — 14:30:00.250 for a quarter-second past 14:30 — with no fixed limit on the number of decimals. RFC 3339 fixes a comma as informative only and the period as the canonical decimal separator on the internet, so writing 14:30:00.250 is the safe choice in protocols that profile the standard.¹³

How is a time zone written?

An ISO 8601 time can carry a time-zone offset by appending either the literal letter Z for Coordinated Universal Time, or a signed hour-and-minute offset such as +10:00 or -05:00 for a local zone. 2026-05-09T14:30:00Z and 2026-05-09T07:30:00-07:00 are the same instant, written from the perspective of UTC and Pacific Daylight Time respectively.¹³

The offset is the difference local-time-minus-UTC, not the other way around. A timestamp written +10:00 is therefore ten hours ahead of UTC — Sydney in summer, not Hawaii. A bare time with no offset and no Z is a local time of day with no anchor to UTC; it is what people mean when they say "5 p.m." without saying where, and it cannot be converted to an instant without external knowledge of the zone.¹

An offset, on its own, does not say which time zone produced the local label — only how far it is from UTC at this particular instant. 2026-05-09T07:30:00-07:00 could be Pacific Daylight Time in Los Angeles, Mountain Standard Time in Phoenix, or any of several other zones that happen to sit at -07:00 on that day. A 2024 IETF specification, RFC 9557, addresses this by adding an optional bracketed IANA time-zone name after the offset: 2026-05-09T07:30:00-07:00[America/Los_Angeles]. The bracketed tag is purely informational from the point of view of the instant, but it lets the timestamp carry the rule set that produced its local label — so a calendar event saved as "9 May 2026, 7:30 a.m. Los Angeles" can survive a future change to that zone's daylight-saving rules.⁴

How does ISO 8601 write durations and intervals?

A duration in ISO 8601 is a length of time with no anchor to a particular instant. It is written with a leading P — for "period" — followed by the year, month, week, and day fields in order, then a T, then the hour, minute, and second fields. Each field is a number followed by its unit letter. P1Y2M3DT4H5M6S is one year, two months, three days, four hours, five minutes, and six seconds; PT1H30M is an hour and a half; P7D is a week.¹

An interval is a span between two instants and is written as two ISO 8601 timestamps joined by a forward slash: 2026-05-09/2026-05-12 spans from 9 May 2026 to 12 May 2026. The same span can also be written as a start instant and a duration — 2026-05-09/P3D — or as a duration and an end instant — P3D/2026-05-12.¹

A recurring interval prepends the literal R followed by an optional repeat count: R5/2026-05-09T09:00:00Z/PT1H means "five times, every hour from 9:00 UTC on 9 May 2026". Recurring intervals are rare in transport formats but appear in calendar systems and in some scheduling APIs.¹

Why does the internet use RFC 3339 instead of ISO 8601 directly?

RFC 3339 is a profile of ISO 8601 — a strict subset, with the standard's grammar simplified and several optional features removed, intended for use in internet protocols. Its abstract states the relationship plainly: "This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar."³ In practice, most software that says "ISO 8601" actually means RFC 3339.

The simplifications are deliberate. ISO 8601 permits dropping the seconds field, dropping all separators, replacing the T with a space, and writing the hour as 24 at end of day; RFC 3339 forbids each of these. The seconds field is mandatory; the date-time separator must be a literal T (though Section 5.6 of the RFC allows applications to substitute a space "for the sake of readability" in unambiguous contexts);³ hyphens and colons are required; and the hour must be in the range 00 to 23 rather than 00 to 24. The offset (or Z) is required, so a bare local time is not a valid RFC 3339 string.³

The motivation is interoperability without negotiation. ISO 8601 is rich because it tries to cover every legitimate human convention; RFC 3339 is narrow because it has to be readable by any compliant parser the first time, with no preceding handshake about which optional features are in use. Almost every web specification that touches dates — JSON Schema's format: "date-time", OpenAPI's date-time type, the HTTP Date header's modern alternative, OAuth 2.0 token expiries, structured logs — references RFC 3339 directly, even though the popular shorthand for the format is "ISO 8601 timestamps".³

Where is ISO 8601 baked into the web platform?

The HTML <time> element exists specifically to attach a machine-readable ISO 8601 string to a piece of human-readable date or time prose. The HTML Living Standard requires the datetime attribute, when present, to "be a representation of the element's contents in a machine-readable format" and parses it against a battery of ISO 8601-shaped grammars covering valid month strings, dates, weeks, times, time-zone offsets, global date-and-time strings, and durations.⁶ Every rendered date on this site uses a <time datetime="…"> wrapper for that reason — the visible text can be written in whatever locale convention the page uses, but the datetime attribute carries the unambiguous form a crawler or screen reader can act on.

The earlier W3C Note on date and time formats, published in 1998, is the original profile-of-ISO-8601 used by RDF, XML Schema, and several other early web standards. It defines six granularity levels, from year-only through fractional-second, and was the document that pinned the literal-T-separator-plus-four-digit-year convention into the web platform.⁵ RFC 3339 came four years later and is now the dominant profile, but the W3C Note is the reason the basic shape was already familiar by the time RFC 3339 codified it.

Outside the platform itself, the IANA Time Zone Database — the operational source of truth for which UTC offset applies where, and how that has changed over time — is the data behind every ISO 8601 timestamp that carries a meaningful offset.⁷ Bracketed time-zone tags from RFC 9557 are the format's way of preserving the rule set used to compute the offset, so a future zone change does not silently shift the local label of an already-recorded instant.⁴

What are the common pitfalls?

Most cross-system bugs around ISO 8601 trace to a small number of edge cases:

• Midnight: 24:00 vs 00:00 of the next day. ISO 8601 permits the hour to be written as 24 to denote the end of the day — 2026-05-09T24:00:00 is the same instant as 2026-05-10T00:00:00. RFC 3339 forbids this and requires hours in the range 00 to 23, so any timestamp crossing internet protocols should use the next-day form. The 24-hour clock page covers the midnight case in more detail.¹³
• Leap-second representation. ISO 8601 allows the seconds field to take the value 60 when a leap second is in progress, and RFC 3339 preserves that — a UTC leap-second instant is written 2016-12-31T23:59:60Z. Unix time has no encoding for that instant; it is a UTC-only feature.³
• The T separator. The standard makes the T required for the combined date-time form. RFC 3339 § 5.6 carves out an explicit exception that lets a single space be used "for the sake of readability" in protocols where the meaning is unambiguous, but accepting that variant is a courtesy, not a requirement. Writing 2026-05-09 14:30:00Z is convenient for log files and risky for wire formats; writing 2026-05-09T14:30:00Z is the only universally safe choice.¹³
• Fractional seconds and precision. The number of fractional digits is not bounded by either standard. A producer that emits nanoseconds and a consumer that expects milliseconds will silently truncate, lose precision, or round depending on its parser. JSON Schema's date-time profile inherits RFC 3339's "any number of digits" rule; receivers that care about precision specify the expected width separately.³
• Extended versus basic format mixing. ISO 8601 is unclear on whether a string can mix extended-format dates with basic-format times; RFC 3339 explicitly permits the mixture but in practice every major parser expects one or the other consistently. Writing all extended (2026-05-09T14:30:00Z) is the only portable choice.³
• Negative time-zone offsets. The offset is local-time-minus-UTC, so an offset of -08:00 means eight hours behind UTC. The Unicode-minus character (U+2212, −) is not a permitted offset sign — only the ASCII hyphen-minus (U+002D, -) is, despite typographic-aware rendering libraries occasionally substituting it.³
• Year 0 and negative years. ISO 8601 uses the proleptic Gregorian calendar — the modern calendar extrapolated backwards through the period before its 1582 introduction — and includes a year 0. The historical convention used by astronomers also uses a year 0, but the convention used by most history books does not (1 BCE is followed directly by 1 CE). An ISO 8601 string of 0000-12-31 is therefore one day before 0001-01-01 — not the same as the historical "31 December 1 BCE".¹
• ISO weeks vs locale weeks. ISO 8601 weeks start on Monday and number 1 is the week containing the first Thursday of the year. Many locales use a different convention — Sunday-first weeks, with week 1 being the week containing 1 January — and the two disagree by up to a week at year boundaries. Consumers reading 2026-W19-6 should verify the producer is using the ISO numbering, not a locale variant.¹

Frequently asked questions