The ISO 8601 Date and Time Format, Fully Explained

An API returns 2026-08-31T14:30:00Z and, without checking any documentation, you know exactly what it means: the 31st of August 2026, half past two in the afternoon, Coordinated Universal Time. Compare that to 08/09/2026 — is that the 8th of September or the 9th of August? Nobody reading that string alone can be certain. That gap between "unambiguous" and "depends who's reading it" is the entire reason ISO 8601 exists.

This guide covers the standard itself, in full: the date and time formats, how they combine, the less-common week-date and ordinal-date forms, how durations are written, and where ISO 8601 ends and RFC 3339 — the profile most web APIs actually use — begins. If you specifically need to convert a Unix timestamp into this format, the timestamp conversion guide covers that; this page is about the notation itself.

ISO 8601 is a standard published by the International Organization for Standardization, most recently revised in 2019, that defines exactly how to write calendar dates, times of day, and durations as plain text. Its job isn't to make a date look nice on a printed page for a human — it's an interchange format, meant for the moment one system hands a date to another: a database column, a JSON field, a log line, a filename. When both sides of that handoff follow the same rule, there's nothing left to misread.

The standard deliberately leaves some things out. It has no concept of a 12-hour clock, no AM/PM, and no named time zones like "Eastern Time" — for the reasoning behind 24-hour notation itself, see how to read the 24-hour clock. What it does define, it defines precisely: four separate representations — calendar date, time of day, week date, and ordinal date — plus a syntax for combining a date with a time and for expressing a span of time.

The most familiar piece of ISO 8601 is its calendar date: a four-digit year, a two-digit month, and a two-digit day, always in that order and always zero-padded — 2026-08-31 for the 31st of August 2026, never 2026-8-31. The hyphens are what the standard calls "extended format"; a compact "basic format" without separators also exists — 20260831 — and shows up mostly in filenames and machine-generated identifiers rather than anything a person reads directly.

The year-month-day order isn't arbitrary. Writing the largest unit first means that two ISO dates sort correctly even as plain text strings, with no date-aware logic required — 2026-01-05 naturally sorts before 2026-08-31. It also sidesteps the regional split between MM/DD/YYYY and DD/MM/YYYY entirely, since neither of those orderings is valid ISO 8601.

Times of day follow the same zero-padded, largest-unit-first logic: two digits for the hour, two for the minutes, two for the seconds, separated by colons in extended format — 14:30:00 for half past two in the afternoon. The clock always runs 00 to 23; there is no AM or PM anywhere in the standard. Basic format drops the colons the same way dates drop their hyphens: 143000.

Fractions of a second, when needed, are added after a decimal mark — 14:30:00.5 for half past two and half a second. The standard's own preference is a comma, but a period is what almost every programming language and API actually emits, and both are accepted. One more allowance is easy to miss: 24:00:00 is a valid way to write the exact end of a day, equivalent to 00:00:00 at the start of the next one — though in practice, systems overwhelmingly write the next day's midnight instead.

Joining a date and a time into one string needs a separator, or 20260831143000 would be an unreadable run of fourteen digits. ISO 8601 solves this with a literal capital letter T: 2026-08-31T14:30:00. The T isn't an abbreviation for anything in particular — it's simply the fixed marker the standard chose to divide the date part from the time part.

What that time actually refers to — whose clock it's on — is a separate question, answered with a suffix. A trailing Z stands for "Zulu time," military and aviation shorthand for UTC, and is exactly equivalent to an offset of +00:00: 2026-08-31T14:30:00Z. For any other zone, the offset is written explicitly as ±hh:mm — 2026-08-31T19:30:00+05:00 is the same instant, five hours ahead of UTC. A date-time with neither a Z nor an offset is technically valid ISO 8601, but it leaves the reader guessing which clock it was written on — for that concept in general, see what UTC actually is.

Four ways to write the same instant, generated from your device's clock and updating as the seconds tick over:

Alongside the calendar date, ISO 8601 defines an entirely separate way to identify a day: by its position in a numbered week. The format is YYYY-Www-D — a four-digit year, a literal W, a two-digit week number, and a day-of-week digit from 1 (Monday) to 7 (Sunday). Monday the 31st of August 2026 is week 36 of that year, so it's written 2026-W36-1.

The rule for where week 1 starts is precise and easy to state, if not entirely intuitive: week 1 of a year is the week that contains that year's first Thursday, which is the same as saying it's the week containing 4 January. Weeks always run Monday to Sunday. One consequence of anchoring to Thursday rather than 1 January is that the boundaries don't line up neatly with the calendar year — the final days of December can fall into week 1 of the following ISO year, and the first days of January can still belong to week 52 or 53 of the year before. Most years have 52 ISO weeks; some have 53.

Week dates aren't something most people write by hand, but they turn up regularly in European fiscal planning, manufacturing schedules, and logistics systems, and in the "week number" a spreadsheet or calendar app shows next to a date.

The least common of the three date forms counts straight through the year: YYYY-DDD, where DDD is a three-digit day-of-year from 001 to 365 (or 366 in a leap year). The 31st of August 2026 is the 243rd day of that year, so its ordinal date is 2026-243.

Ordinal dates are rare in everyday writing but do appear in manufacturing date codes, some scientific data formats, and older mainframe and inventory systems where a fixed-width day count was cheaper to store and compare than a month-and-day pair. If you come across a seven-character date with no separator between the last three digits, this is very likely what it is.

ISO 8601 also defines a syntax for a length of time, rather than a point in time. A duration starts with a literal P (for "period"), followed by a number and a unit for each component: Y for years, M for months, D for days, then — if any time components follow — a literal T, then H for hours, M for minutes, and S for seconds. The T is what tells M apart from M: before it, M means months; after it, M means minutes.

Short durations drop whatever isn't needed: PT30M is simply 30 minutes, and P7D is 7 days with no time component at all, so no T is needed. Durations combine with dates to express intervals — a start and an end (2026-08-01T00:00:00Z/2026-08-31T23:59:59Z), or a start and a duration (2026-08-01T00:00:00Z/P30D) — though the precise arithmetic for adding or measuring spans of time on a calendar is its own topic, covered in the guide to adding and subtracting time.

Almost every "ISO format" timestamp seen in a web API, a JSON payload, or an HTTP header is, strictly speaking, following RFC 3339 — a specification published by the Internet Engineering Task Force that describes itself as a profile of ISO 8601 built specifically for internet protocols. It isn't a rival standard; it's a deliberately narrowed slice of ISO 8601's much larger rulebook, chosen because a full ISO 8601 parser has to handle far more variation than any single API needs to produce.

The narrowing runs one direction: RFC 3339 always requires an explicit UTC offset or Z on a date-time, where ISO 8601 permits leaving it off. RFC 3339 doesn't include the week-date or ordinal-date forms at all, and it doesn't use the separator-free basic format — every RFC 3339 timestamp uses hyphens and colons. In exchange, RFC 3339 relaxes a couple of things ISO 8601 is stricter about, such as allowing a lowercase t or even a plain space in place of the capital T. In practice: every valid RFC 3339 string is valid ISO 8601, but the reverse isn't guaranteed.

• Calling MM/DD/YYYY or DD/MM/YYYY "ISO format." Neither is ISO 8601 — the standard fixes the order as year, month, day with hyphens, with no regional variation.
• Dropping the offset and assuming it's implied. A date-time with no Z and no ±hh:mm is valid but ambiguous about whose clock it's on.
• Assuming ISO week 1 always begins on 1 January. It begins on the Monday of the week containing the year's first Thursday, which can fall in late December of the previous year.
• Treating 24:00:00 as an error. It's a valid way to write the instant at the end of a day, even though 00:00:00 the next day is far more common in practice.
• Assuming any string with hyphens and a T is automatically valid ISO 8601. A malformed or truncated variant — a missing leading zero, a two-digit year, an invalid month — is still invalid, appearances aside.