What is the ISO 8601 datetime format?

Short answer

ISO 8601 defines standard ways to write dates and times so computers can exchange them unambiguously. It covers Gregorian calendar dates and 24-hour times as character strings, including representations tied to Coordinated Universal Time (UTC) and time shifts (offsets) for interchange (ISO 8601-1:2019). It is a family of representations, not a single one-size-fits-all string, which is why many Internet protocols adopt a simpler profile such as RFC 3339.

How ISO 8601 datetime is typically written

In practice, many systems use an extended datetime form like YYYY-MM-DDThh:mm:ss with optional fractional seconds and either the UTC designator Z or a numeric offset such as +01:00. The widely used Internet profile RFC 3339 requires the extended date and time, the literal T separator, and a UTC indicator (Z or a numeric offset). It also defines how strings can be sorted when timezone and precision are consistent and notes case-insensitive T/Z with uppercase recommended.

Three complete example timestamps

These are illustrative timestamps, not recorded events. The first two identify the same instant; the third is 250 milliseconds later. The numeric offset describes the offset at that instant, not a named region or its future daylight-saving rules (RFC 3339).

• 2026-10-24T13:45:30Z: 13:45:30 in UTC.
• 2026-10-24T15:45:30+02:00: 15:45:30 at UTC+02:00, equal to the first timestamp.
• 2026-10-24T13:45:30.250Z: the UTC example with a fractional second.

ISO 8601 vs RFC 3339

• Scope: ISO 8601 covers dates, times, and combinations, including week dates and ordinal dates; it allows compact (no separators) and extended (with separators) forms (ISO 8601-1:2019). RFC 3339 is a profile tailored for Internet timestamps and is intentionally simpler (RFC 3339).
• Timezone requirement: RFC 3339 requires a stated relationship to UTC for all times (either Z or an offset) and defines the semantics of numeric offsets (RFC 3339, Sections 1 and 4.2). ISO 8601 allows local times without an offset in some representations, but that invites ambiguity in network protocols.
• Allowed hour values: ISO 8601 permits 24:00 to mark the end of a day, while RFC 3339 restricts hours to 00-23 to reduce confusion (RFC 3339, Section 5.7).
• Sorting and case: When timezone designators and fractional precision are uniform, RFC 3339 strings sort lexicographically in time order; it also notes that T and Z may be lowercase, though generators should use uppercase (RFC 3339, Sections 5.1 and 5.6).

Offsets, UTC and calendar validity

• UTC designator: A trailing Z means the timestamp is in UTC (+00:00) (RFC 3339, Definitions).
• Numeric offsets: Offsets are written as +hh:mm or -hh:mm and represent local time minus UTC. For example, 18:50:00-04:00 equals 22:50:00Z (RFC 3339, Section 4.2).
• Calendar limits: Day-of-month maxima vary by month and leap years; profile rules summarize valid ranges (RFC 3339, Section 5.7).
• Leap seconds: Second values of 60 can occur at the end of certain months as a leap second; many systems do not handle them uniformly, so test accordingly (RFC 3339, Section 5.7).

When to use ISO 8601 and what to publish

Use ISO 8601 for machine-readable dates in APIs, data exchange, and filenames where sorting by date matters. UK government guidance explicitly recommends ISO 8601 for APIs and inter-system data and explains the extended form with T, 24-hour time, and readable separators, with examples of UTC offsets like +01:00 (GOV.UK: Formatting dates and times in data). For web protocols, adopting the RFC 3339 profile is a pragmatic choice that aligns with common parsers (RFC 3339).

Before you publish timestamp examples, test them with the actual parser and formatter your application uses. Record which representations your API accepts and rejects.

Choose and document your subset

• Representation: Prefer the extended form YYYY-MM-DDThh:mm:ss for readability. If you need sub-second precision, include fractional seconds and define your maximum precision.
• Timezone policy: Require Z or a numeric offset for all API timestamps to avoid ambiguity. If you must accept naive inputs, document exactly how you interpret them and where you reject them.
• Validation: Define parse/format tests per supported runtime. Keep your validation checks simple and strict to avoid accepting ambiguous inputs. You can adapt a similar mindset from our validation workflow (How to validate schema markup: a practical checklist).

Common pitfalls and safe practices

• Missing offsets: Unqualified local times lead to misinterpretation across time zones. RFC 3339 requires an explicit UTC relationship for interoperability (RFC 3339, Section 1).
• Separators and case: Use T as the date-time separator and prefer uppercase. While t/z may be accepted, generators should emit uppercase, and many parsers expect T (RFC 3339, Section 5.6).
• Sorting assumptions: Lexicographic sort works only when your strings use the same timezone designator and the same fractional precision (RFC 3339, Section 5.1).
• Human display vs storage: Store canonical machine formats and localize for UI; this avoids accidental timezone shifts. For general web content that needs a date-only display, the ISO date format YYYY-MM-DD is unambiguous for readers and machines (W3C Quality Web Tips).

FAQ