Why the order matters
Dates written as day/month/year or month/day/year are ambiguous as soon as both numbers are 12 or below. ISO 8601 fixes the order as year, month, day, with two digits for month and day, and the same largest-first rule for the time: hours, minutes, seconds. Two consequences follow. The format is unambiguous across countries, and because every field has a fixed width, a list of ISO dates sorts chronologically with a plain text sort, in a file name, a spreadsheet column or a log file.
The formats most software uses
ISO 8601 itself allows many variants. The W3C note that most web standards follow restricts it to six, with the stated aim of reducing the scope for error and the complexity of software:
| Format | Example | Meaning |
|---|---|---|
| YYYY | 1997 | Year |
| YYYY-MM | 1997-07 | Year and month |
| YYYY-MM-DD | 1997-07-16 | Complete date |
| YYYY-MM-DDThh:mmTZD | 1997-07-16T19:20+01:00 | Date, hours and minutes, with zone |
| YYYY-MM-DDThh:mm:ssTZD | 1997-07-16T19:20:30+01:00 | Plus seconds |
| YYYY-MM-DDThh:mm:ss.sTZD | 1997-07-16T19:20:30.45+01:00 | Plus a decimal fraction of a second |
TZD is the time zone designator: Z for UTC, or +hh:mm and -hh:mm for a local time that many hours and minutes ahead of or behind UTC. The W3C note also points out that the full standard lets the century be omitted from a year, and excludes that on purpose; four-digit years always.
T, Z and the offsets
- T separates the date from the time. RFC 3339 allows a space instead for readability, and lowercase t, but says generators should write upper case T.
- Z is a suffix meaning an offset of 00:00: the time is UTC. +00:00 means the same.
- +hh:mm or -hh:mm is the local offset, defined as local time minus UTC. 16:39:57-08:00 is 00:39:57Z the next day. Offsets are whole minutes; half-hour zones such as +05:30 are fine, but historical odd offsets cannot be written exactly, which is why RFC 3339's Netherlands example uses +00:20 as the nearest representable value.
- -00:00, with a minus sign, is RFC 3339's way of saying the UTC time is known but the local offset is not.
The offset tells you the local clock; it does not name the zone. 2026-07-04T09:00-04:00 could be New York in summer or Santiago in winter. If the zone matters, carry its IANA name alongside, such as America/New_York; the UTC and time zones guide covers why.
RFC 3339, the internet profile
RFC 3339 describes itself as an internet profile of ISO 8601 and a conformant subset of its extended format, with stricter rules: the complete date is always written, the T separator is used, hours run 00 to 23 (ISO 8601 also permits 24), and offsets are whole minutes. Its examples are the ones to copy:
| Timestamp | Meaning |
|---|---|
| 1985-04-12T23:20:50.52Z | 23:20:50.52 UTC on April 12, 1985 |
| 1996-12-19T16:39:57-08:00 | Pacific Standard Time; the same instant as 1996-12-20T00:39:57Z |
| 1990-12-31T23:59:60Z | The leap second at the end of 1990, in UTC |
| 1990-12-31T15:59:60-08:00 | The same leap second, written in Pacific Standard Time |
The two leap second rows show a detail most software ignores: the seconds field can legitimately read 60 at the end of a day on which a leap second is inserted. Most libraries will refuse it or roll it over; if you parse other people's timestamps, expect it.
ISO 8601 or a Unix timestamp?
| ISO 8601 / RFC 3339 | Unix timestamp | |
|---|---|---|
| Looks like | 2026-10-20T14:30:00Z | 1792506600 |
| Readable by people | Yes | No |
| Carries a local offset | Yes, when written with one | No, always UTC |
| Sorts as text | Yes, within one offset | Yes |
| Arithmetic | Needs a library | Subtract two numbers |
| Typical use | APIs, logs, file names, documents | Databases, caches, signatures |
A common pattern is to store the Unix timestamp and display ISO 8601. The Unix timestamp converter goes both ways and shows the ISO form in UTC and in your zone. For date arithmetic that people need to read, the days between dates calculator and the time zone converter accept ISO dates directly, and the Julian date converter covers the older day-count systems astronomers still use.
Rules of thumb
- Write dates as YYYY-MM-DD everywhere a human and a machine both read them: file names, spreadsheet columns, document headers.
- Write timestamps with an offset or a Z, never a bare time. A time without a zone is a time without a meaning.
- Prefer UTC (Z) for anything stored or exchanged between systems, and convert to local time only for display.
- Keep four-digit years and two-digit months and days; 2026-7-4 is not ISO 8601 and will not sort.
Frequently asked questions
What is the ISO 8601 date format?
Year, month, day, from the largest unit to the smallest, with fixed widths and hyphens: 2026-10-20 for a date, and 2026-10-20T14:30:00Z for a date and time in UTC. The order is the whole point: it is unambiguous between countries and sorts correctly as plain text.
What does the T mean?
It separates the date from the time. RFC 3339 notes that ISO 8601 defines date and time separated by a T, that applications may use a space instead for readability, and that the T and the Z may be lowercase, though generators should use upper case.
What does the Z at the end mean?
A UTC offset of zero: the time is Coordinated Universal Time. RFC 3339 defines Z as a suffix denoting an offset of 00:00, and treats Z and +00:00 as meaning UTC is the preferred reference. Any other zone is written as a numeric offset such as -08:00 or +05:30, computed as local time minus UTC.
Is RFC 3339 the same as ISO 8601?
RFC 3339 is an internet profile of ISO 8601, a conformant subset of its extended format with stricter rules: the full date is always written, hours run only from 00 to 23, offsets are whole minutes. Anything valid under RFC 3339 is valid ISO 8601; the reverse is not always true.
Why not just use a Unix timestamp?
A Unix timestamp is a count of seconds since 1970-01-01T00:00:00Z, compact and zone-free, which makes it ideal for storage and arithmetic. It is also unreadable, and it cannot say which local time an event was written in. ISO 8601 with an offset carries both the instant and the local context, which is why logs, APIs and file names tend to use it, and the Unix timestamp converter turns one into the other.
Sources
- W3C Note: Date and Time Formats (the profile of ISO 8601 with the six formats, the TZD rules Z, +hh:mm and -hh:mm, and the reasons for restricting the standard)
- RFC 3339: Date and Time on the Internet: Timestamps (the internet profile of ISO 8601, the T separator, Z and numeric offsets, -00:00 for unknown local offset, the section 5.8 examples including leap seconds)