ISO 8601 Beyond YYYY-MM-DD

Week dates, ordinal dates, durations, intervals, and the recurring forms most developers never see.

Last reviewed on 25 April 2026.

Most developers know ISO 8601 as YYYY-MM-DD and the timestamp form with the trailing Z. The standard is much larger than that. It defines a coherent way to write any moment, span, or repeat in a machine-readable form, and several of the lesser-known shapes solve problems that recur in business reporting, scheduling, and APIs. This page is a working tour of the parts that go beyond the basic date.

Calendar dates, recap

The form everyone knows: YYYY-MM-DD for an extended representation, or YYYYMMDD for the basic representation. The standard distinguishes "extended" (with separators, easier to read) and "basic" (without separators, more compact). Modern usage is overwhelmingly extended; basic shows up in older file formats and some embedded systems.

Ordinal dates: the day of the year

An ordinal date is a year plus the day-of-year (1 to 365 or 366). The form is YYYY-DDD:

Ordinal dates are useful when you care about elapsed days more than calendar months — astronomy, agriculture, batch numbering, and certain manufacturing systems use them. They round-trip to a normal date through any standards-compliant date library, and most languages can convert between the two forms in one call.

Week dates: the unloved sibling

The week date form is YYYY-Www-D: a year, a week number, and a day-of-week (1 = Monday, 7 = Sunday).

The trap: the ISO week year is not the calendar year

The ISO standard defines week 1 as the week that contains the first Thursday of the year, which is equivalent to "the week containing 4 January". A consequence is that the ISO week year can disagree with the calendar year for up to three days at each end. The 30 December 2024 falls in ISO week 1 of 2025; the 1 January 2026 falls in ISO week 1 of 2026, but 31 December 2024 falls in ISO week 1 of 2025 in the same way.

If you are computing "the year" from a date for reporting purposes, decide deliberately: do you want the calendar year or the ISO week year? Mixing them silently is a popular source of off-by-one errors in year-end reports.

Where week dates are used

Industry that runs on weekly cycles tends to live in week dates: production planning, retail merchandising, payroll, and some financial reporting. A spreadsheet that says "WK 18, 2025" is almost certainly an ISO week date, even if no one in the room knows the ISO number.

Times

Time alone uses the form hh:mm:ss, optionally with a fractional second separator (period or comma) and a zone designator. 23:59:59, 23:59:59.500, 23:59:59Z, and 23:59:59+05:30 are all valid.

A few subtleties:

Combined date and time

The combined form uses T as the separator: 2025-04-03T14:30:00Z. The T is mandatory in the standard, even though many systems accept a space. If you are generating values for an API, write the T — it is what consumers expect and what RFC 3339 (the Internet profile of ISO 8601) requires.

Durations

A duration is an amount of time, written as P[n]Y[n]M[n]DT[n]H[n]M[n]S. The P prefix is mandatory; the T separates date components from time components.

Two warnings: durations expressed in months and years are not constant amounts of time (a "month" can be 28 to 31 days), and not every parser supports the week form alongside the others. For amounts you intend to add to a moment, prefer absolute units (days, hours, seconds) when precision matters and calendar units only when "the same day next month" is what you actually mean.

Time intervals

An interval has a start and an end, written in any of three shapes:

The slash is the interval separator. By convention the interval is half-open: it includes the start and excludes the end, which matches the half-open range pattern recommended for database queries. Be explicit in your API documentation either way; readers should not have to guess.

Recurring intervals

The form is R[n]/<interval>: an R, an optional repetition count, and an interval. Without a count, the recurrence is unbounded.

Recurring intervals describe the regular case well, but they cannot express things like "the second Tuesday of every month" or "every weekday except holidays". For those, the iCalendar standard's RRULE syntax is the usual choice; ISO 8601 stops at evenly spaced repetition.

Worked example: a backup window

"Run a backup every day for an hour starting at 02:30 UTC for the next 30 days." In ISO 8601:

R30/2025-04-25T02:30:00Z/PT1H

The same window expressed as a single date and a daily count would lose the duration. As a list of timestamps it would be 30 lines. The recurring interval form captures the rule in one line, and a parser can produce the 30 individual instants on demand.

Time zones in ISO 8601

The standard supports two zone forms:

ISO 8601 does not include IANA zone names like Europe/Frankfurt. An offset captures the moment unambiguously, but it does not capture the zone's identity, which matters for future events because daylight-saving rules change. If you need to preserve the zone (not just the moment), carry the IANA name alongside the ISO 8601 string. The time zones page covers the broader picture.

Common mistakes

Why bother with the rare forms

Ordinals, week dates, durations, and recurring intervals are not exotic — they show up in spreadsheets, in batch jobs, in backup configurations, and in protocols you may end up implementing. The pay-off for knowing them is quiet: when a system speaks ISO 8601 fluently, the conversation between two services becomes a single string instead of a struct full of named fields, and the meaning is the same on either side.

Related reading