ISO 8601 Date and Time Format

ISO 8601 is the unsung infrastructure of every modern date-time system. Internet APIs, databases, log files, file names, and inter-system messages all benefit from a single unambiguous format that anyone can parse without locale assumptions. This article covers the ISO 8601 standard itself, the RFC 3339 internet subset, the various forms (datetime, ordinal, week, duration, interval), the sortable property, and frequent pitfalls.

Companion to /learn/utc-explained, /learn/time-zones-explained, and /learn/iana-time-zone-database. This is the close-out article for the Time & Time Zones sub-hub.

The basic datetime format

The canonical ISO 8601 datetime, in extended format:

YYYY-MM-DDThh:mm:ss±hh:mm

For UTC:

YYYY-MM-DDThh:mm:ssZ

Worked example: May 24, 2026 at 17:30:00 UTC:

2026-05-24T17:30:00Z
2026-05-24T17:30:00+00:00      (equivalent)
2026-05-24T17:30:00.123Z       (with fractional seconds)
2026-05-24T17:30:00-05:00      (same instant, US Eastern Standard Time)
2026-05-24T23:00:00+05:30      (same instant, India Standard Time)

Each part has fixed width and is zero-padded if necessary:

• YYYY — 4-digit year (or more for >9999; or negative for years before 1)
• MM — 2-digit month (01–12)
• DD — 2-digit day (01–28/29/30/31)
• T — literal “T” separator (uppercase per ISO 8601; lowercase or single space allowed by RFC 3339)
• hh — 2-digit hour (00–23 for 24-hour clock; 24:00:00 is also valid per ISO 8601 as the end of the day, but rarely used)
• mm — 2-digit minute (00–59)
• ss — 2-digit second (00–60; 60 allowed for leap seconds)
• ±hh:mm — UTC offset (e.g., +05:30, -08:00) or literal Z for UTC

Basic vs extended

ISO 8601 defines two related formats:

• Extended: with separators (- between date parts, : between time parts). Example: 2026-05-24T17:30:00Z. Human-readable.
• Basic: without separators. Example: 20260524T173000Z. Compact, often used in filenames and headers where separators are problematic.

The two formats represent the same information; converting between them is mechanical. Mixed formats (some separators but not others) are not ISO 8601 compliant.

Date-only and time-only

The standard supports date-only and time-only forms:

2026-05-24          (date only)
17:30:00            (time only)
17:30:00.123        (time only with fractional seconds)
17:30:00Z           (time only in UTC)
17:30:00-05:00      (time only with offset)

A bare date (no time) is sometimes used for calendar dates where the time of day is irrelevant (e.g., a birthday). A bare time is rarely useful in practice — most applications need either a full datetime or a date.

Ordinal dates

An ordinal date identifies a day by year + day-of-year:

YYYY-DDD             (extended)
YYYYDDD              (basic)

Worked example: 2026-144 represents May 24, 2026 — the 144th day of 2026.

| Date | Ordinal | | ------------- | ------------- | | 2026-01-01 | 2026-001 | | 2026-02-01 | 2026-032 | | 2026-05-24 | 2026-144 | | 2026-12-31 | 2026-365 | | 2024-12-31 | 2024-366 |

Ordinal dates appear in some scientific contexts, military date formats (the so-called “Julian date” in informal usage — not the same as the astronomical Julian Day Number), and some IANA tz database internal records.

Week dates

The week date format identifies a day by year + ISO week + day-of-week:

YYYY-Www-D           (extended)
YYYYWwwD             (basic)

Where ww is the ISO week number (01–53) and D is the ISO day-of-week (1 = Monday, 7 = Sunday).

The ISO week definition: Week 1 of a year is the week containing the first Thursday of that year. Equivalently: the week containing January 4 of the year. Equivalently: the week containing the first day of the year having at least four days in the new year.

This definition means that the week-date year may differ from the calendar year for dates near a year boundary:

| Calendar date | Week date | | ------------- | ------------- | | 2025-12-29 (Mon) | 2026-W01-1 | | 2025-12-30 (Tue) | 2026-W01-2 | | 2025-12-31 (Wed) | 2026-W01-3 | | 2026-01-01 (Thu) | 2026-W01-4 | | 2026-01-04 (Sun) | 2026-W01-7 | | 2026-01-05 (Mon) | 2026-W02-1 |

Conversely, January 1, 2027 falls on a Friday, so 2026-W53 exists (rare years like 2026 with 53 ISO weeks include years starting Thursday or leap years starting Wednesday).

Week dates are common in European business and manufacturing contexts (week-numbered planning calendars, ERP systems), rare in U.S. usage.

Durations

A duration represents a length of time:

PnYnMnDTnHnMnS

Each n is a number (may have a decimal); the letters are literal: P = period, Y = year, M = month, D = day, T = separator before time components, H = hour, M = minute, S = second.

Worked examples:

| Duration | Meaning | | -------- | ------- | | P3Y | 3 years | | P6M | 6 months | | P4D | 4 days | | PT12H | 12 hours | | PT30M | 30 minutes | | PT45S | 45 seconds | | P3Y6M4DT12H30M5S | 3 years, 6 months, 4 days, 12 hours, 30 minutes, 5 seconds | | PT1.5H | 1.5 hours | | P1W | 1 week (alternative form, doesn't combine with other parts) |

The M is overloaded — it means “months” before the T and “minutes” after. A common gotcha.

Durations are calendrical, not exact instants: “P1M” (one month) can mean 28, 29, 30, or 31 days depending on context. Adding P1M to 2026-01-31 might give 2026-02-28 (in some implementations) or 2026-03-03 (in others). Exact-instant durations should be expressed in PTnH, PTnM, or PTnS form.

Intervals

An interval has a start and end:

<start>/<end>
2026-05-24T17:30:00Z/2026-05-24T18:30:00Z

Or a start and a duration:

<start>/<duration>
2026-05-24T17:30:00Z/PT1H

Or a duration and an end:

<duration>/<end>
PT1H/2026-05-24T18:30:00Z

A repeating interval prepends Rn/ where n is the number of repetitions (or empty for unbounded):

R3/2026-05-24T17:30:00Z/PT1H
   meaning: 3 repetitions of a 1-hour interval starting at the given time
R/2026-05-24T17:30:00Z/P1D
   meaning: unbounded repetition of daily intervals starting at the given time

Repeating intervals are widely used in calendar systems (iCalendar RFC 5545 borrows similar syntax) and in some job-scheduling systems.

RFC 3339: the internet subset

RFC 3339 (2002), by Klyne and Newman, is the IETF's profile of ISO 8601 for internet protocols. Most APIs, JSON Schemas, HTTP headers (Date alternative), and internet timestamps follow RFC 3339 rather than full ISO 8601.

Key differences:

| Feature | ISO 8601 | RFC 3339 | | ------- | -------- | -------- | | UTC offset | Optional | Required | | Date/time separator | T uppercase | T, t, or single space | | Year 0 | Allowed (astronomical) | Prohibited | | Reduced precision | Allowed (2026-05) | Prohibited | | Ordinal/week dates | Defined | Prohibited | | Duration syntax | Defined | Prohibited | | Negative years | Allowed | Prohibited |

For internet use:

✓ RFC 3339:  2026-05-24T17:30:00Z
✓ RFC 3339:  2026-05-24t17:30:00+05:30
✓ RFC 3339:  2026-05-24 17:30:00Z

✗ Not RFC 3339:  2026-05-24T17:30:00     (no offset)
✗ Not RFC 3339:  2026-W21-7T17:30:00Z    (week date)
✗ Not RFC 3339:  2026-144T17:30:00Z      (ordinal date)
✗ Not RFC 3339:  P3Y6M4D                 (duration)

When designing an API or wire format, prefer RFC 3339: it removes the most common ambiguities.

The sortable property

ISO 8601 extended-format dates and datetimes are lexicographically sortable as strings: a string alphabetic sort produces chronological order.

Why this works: the format places the most significant field first (year), then less significant (month, day, hour, minute, second), each zero-padded. So 2026-01-15 < 2026-05-24 < 2026-12-31 both numerically and alphabetically.

The property holds for datetimes if all share the same UTC offset:

2026-05-24T01:00:00Z
2026-05-24T02:00:00Z
2026-05-24T03:00:00Z

These sort correctly as strings. But mixed-offset timestamps need parsing for correct chronological ordering — 2026-05-24T17:30:00+05:30 precedes 2026-05-24T13:00:00Z chronologically but follows it in lexical order. The fix: convert all timestamps to UTC before storing/sorting.

This property makes ISO 8601 ideal for filenames:

log-2026-05-24-17-30-00.txt    (sortable by name = sortable by time)
log-20260524T173000.txt        (basic format, even more compact)

vs. localized formats (log-May 24, 2026.txt, log-24/05/2026.txt) which require parsing for chronological sorting.

Common encodings

JSON (no native date type; ISO 8601 strings are convention):

{
  "created": "2026-05-24T17:30:00Z",
  "expires": "2027-05-24T17:30:00Z"
}

JSON Schema's format: "date-time" specification delegates to RFC 3339.

XML Schema dateTime is an ISO 8601 superset, allowing extra precision and explicit timezone:

<created>2026-05-24T17:30:00Z</created>
<expires>2027-05-24T17:30:00-05:00</expires>

HTML5 <time> element:

<time datetime="2026-05-24T17:30:00Z">May 24, 2026</time>

YAML 1.1+ datetime native type:

created: 2026-05-24T17:30:00Z

Filename convention for sortable log/backup files:

backup-2026-05-24T17-30-00.tar.gz

(Colons in filenames cause problems on some systems; substitute hyphens or use the basic format 20260524T173000.)

Frequent pitfalls

The 12:00 confusion: T12:00:00 is noon, not midnight. ISO 8601 uses 24-hour time exclusively; T00:00:00 is midnight at the start of the day.

24:00:00: ISO 8601 allows T24:00:00 as the end of the day — equivalent to T00:00:00 of the next day. RFC 3339 prohibits this. Many parsers reject it; safer to use the next-day midnight form.

Year 0 confusion: ISO 8601 uses astronomical year numbering: year 1 BCE is year 0, year 2 BCE is year -1, etc. This contradicts historical convention (no year 0 in the Gregorian calendar). RFC 3339 prohibits year 0 to sidestep the issue.

Missing offset: a naive timestamp 2026-05-24T17:30:00 (no Z, no offset) is ambiguous. ISO 8601 allows it (local time, no zone information); RFC 3339 prohibits it. Always require an offset in API design.

Truncated forms: ISO 8601 allows representations like 2026, 2026-05, 2026-05-24T17, etc. These reduce precision but are valid. RFC 3339 prohibits them. Most parsers don't handle all the truncated forms; prefer full precision.

Locale-dependent formats: 05/24/2026 is U.S. format (MM/DD/YYYY); 24/05/2026 is European (DD/MM/YYYY); ISO 8601 is 2026-05-24 (YYYY-MM-DD) and is unambiguous. Never use locale-dependent formats in inter-system messages.

Common misconceptions

“ISO 8601 is the same as RFC 3339.” RFC 3339 is a stricter subset. Most RFC-3339-compliant timestamps are ISO 8601 compliant, but ISO 8601 allows many representations RFC 3339 doesn't (ordinal dates, week dates, durations, intervals, naive times, truncated forms).

“ISO 8601 dates are always sortable.” They are when in extended format and all use the same UTC offset. Mixed-offset datetimes need parsing for chronological ordering. The fix: convert all timestamps to UTC before sorting.

“The T is optional.” Per ISO 8601 it's required between date and time. RFC 3339 allows lowercase t or a single space as a more lenient alternative. The literal omission is non-compliant in both.

“Fractional seconds use a period.” They can use either . or , per ISO 8601 (, is the ISO-preferred decimal separator in many locales). RFC 3339 allows only .. For interoperability, use ..

“Years before 1583 are valid in ISO 8601.” ISO 8601 specifies the proleptic Gregorian calendar: the modern Gregorian rules are extended backward in time even to dates before the Gregorian reform (1582). A date like 1500-01-01 in ISO 8601 is the date the Gregorian calendar would have called January 1, 1500, not the actual Julian-calendar January 1, 1500 (the two are about 10 days apart). For historical dates, both conventions should be flagged explicitly.

“ISO 8601 will break in year 10000.” The standard allows expanded representations with explicit sign and additional digits for years outside the “normal” range (e.g., +10000-01-01 or -1500-01-01). RFC 3339 limits to four-digit years. Practical applications should plan for the year-10000 case if expected to outlive that.

“The duration P1M is one month of 30 days.” “P1M” is one month, which can be 28, 29, 30, or 31 days depending on the starting date. For exact-duration purposes, use P30D or PT720H to make it explicit.

“ISO 8601 covers time zones by name.” It covers UTC offsets (±hh:mm or Z), not IANA zone names. A timestamp like 2026-05-24T17:30:00-05:00 doesn't say whether the source is New York, Toronto, or some other -05:00 location. For full zone-aware applications, combine ISO 8601 with an IANA zone name as a separate field: serialize the timestamp in UTC plus the zone name (America/New_York) for presentation.