ISO 8601 Date Format — YYYY-MM-DD
The international standard for writing dates and times. The patterns, the rules behind them, and a converter for checking your own.
The ISO 8601 patterns
Extended format
- YYYY-MM-DD
- 2024-07-15 — a date on its own
- YYYY-MM-DDTHH:mm:ssZ
- 2024-07-15T14:30:00Z — an instant, in UTC
- YYYY-MM-DDTHH:mm:ss±HH:MM
- 2024-07-15T14:30:00+02:00 — an instant, with a local offset
Basic format — no separators
- YYYYMMDDTHHmmssZ
- 20240715T143000Z — AWS X-Amz-Date, iCalendar
- YYYYMMDDTHHmmss±HHmm
- 20240715T143000+0200 — the same, with a local offset
Alternative calendars
- YYYY-Www-D
- 2024-W29-1 — week date — business planning
- YYYY-DDD
- 2024-197 — ordinal date — astronomy, satellite data
Reduced precision
- YYYY-MM
- 2024-07 — a whole month
- YYYY
- 2024 — a whole year
Every example above is the same day, 15 July 2024 — except the reduced-precision forms, which denote a whole month and a whole year. As input, this tool reads the extended calendar and timestamp forms; the basic, week and ordinal forms it produces as output only.
What is the ISO 8601 date format?
ISO 8601 is the international standard for representing dates and times as text. The ISO date format writes the components largest-first in a fixed year-month-day order (YYYY-MM-DD), which removes the ambiguity every locale-specific format has. Adding a time joins the two with a T separator and states the offset from UTC: 2024-07-15T14:30:00Z. It is the basis for RFC 3339 (internet timestamps), for the HTML datetime attribute, and for JavaScript's Date.toISOString().
Why YYYY-MM-DD?
It sorts correctly as plain text
Because the components run from most significant to least, sorting the strings alphabetically sorts the dates chronologically. No parsing, no date type — a SELECT … ORDER BY on a text column, the default order in a file listing, and sort in a shell all come out right. RFC 3339 names this as the reason for the ordering: with a common offset and a fixed number of fractional digits, timestamps "may be sorted as strings […] and a time-ordered sequence will result".
2023-12-01 < 2024-07-15 < 2024-07-16 — sorted
12/01/2023 > 07/15/2024 — an earlier date sorting last
This is also why the fixed width matters: 2024-7-5 is not ISO 8601. Months and days are always two digits, zero-padded, or the sort breaks.
It is unambiguous across countries
10/11/1996 is 10 November in most of the world and 11 October in the United States, and nothing in the string says which. RFC 3339 calls that format "completely unsuitable for global interchange" for exactly this reason. 1996-11-10 can only be read one way.
It is the standard, not a convention
The order is fixed by ISO 8601-1:2019 and inherited by the formats built on it — RFC 3339, HTML, XML Schema, SQL, JSON APIs by convention. Choosing it is choosing the thing other software already expects.
Basic and extended format
ISO 8601 defines two ways to write the same value. The extended format keeps the separators (2024-07-15T14:30:00Z) and is what almost everything uses. The basic format drops them (20240715T143000Z) and survives where punctuation does not: AWS Signature V4's X-Amz-Date header, iCalendar, and filenames. The two must not be mixed inside one value — a basic date with an extended time is not legal.
Reduced precision
Trailing components can be dropped from the right to express a less precise value: 2024-07 is the month of July 2024 and 2024 is the year. This is a genuinely coarser value, not a date with unknown parts. Note that a truncated time follows the same rule — 2024-07-15T14:30Z omits the seconds, which ISO 8601 permits but RFC 3339 does not.
Weekday numbering
In an ISO week date the day runs 1 = Monday through 7 = Sunday. JavaScript's Date.getDay() runs 0 = Sunday through 6 = Saturday. The two agree for Monday to Saturday and differ only on Sunday, which is the awkward part: code that ignores the difference is right six days a week and wrong on the seventh. Converting is getDay() || 7.
ISO 8601 vs RFC 3339
RFC 3339 is a profile of ISO 8601 for internet timestamps. It is very nearly a subset: it makes optional things mandatory and drops what is rarely used, so almost every RFC 3339 timestamp is also legal ISO 8601. The clearest exception is -00:00, which RFC 3339 defines and ISO 8601 forbids — see the note under the table. If an API says "ISO 8601" it usually means this profile.
| Feature | ISO 8601 | RFC 3339 |
|---|---|---|
| Date without a time | 2024-07-15 | not a date-time |
| Date/time separator | T, or omitted in some contexts | T (or t); space by agreement |
| Seconds | optional | required |
| Fractional seconds | optional, "." or "," | optional, "." only |
| Offset | optional | required |
| Offset without a colon | +0200 | not allowed |
| Negative zero offset | not allowed | -00:00 = offset unknown |
| Hour 24 (end of day) | 24:00:00 | not allowed |
| Leap second | 23:59:60 | 23:59:60 |
| Basic format | 20240715T143000Z | not allowed |
| Week and ordinal dates | 2024-W29-1, 2024-197 | not allowed |
| Reduced precision | 2024-07 | not allowed |
| Durations and intervals | P1DT2H, start/end | out of scope |
The -00:00 row is the one that surprises people: RFC 3339 gives it a distinct meaning — the instant is known in UTC but the local offset is not — where Z and +00:00 assert that UTC is the intended reference. ISO 8601 does not permit a negative zero offset at all.
Editions: 8601:2004, 8601-1 and 8601-2
The standard people cite as "ISO 8601:2004" no longer exists. It was withdrawn on 2019-02-25 and replaced the same day by two parts, so a current citation names a part number. The content did not change out from under you — the split separates the everyday rules from a large set of extensions almost nobody implements.
ISO 8601-1:2019 — Basic rules
Calendar, ordinal and week dates; times; UTC and offsets; combined date-times; durations and intervals. This is the part that defines everything on this page. Published 2019-02, amended 2022 (technical corrections).
ISO 8601-2:2019 — Extensions
Uncertain and approximate dates, dates with parts unspecified, extended intervals, divisions of a year, sets and choices of dates, repeat rules and date arithmetic. Published 2019-02, amended 2025. Best known through EDTF, which libraries and archives use.
Both parts were confirmed in ISO's 2024 review and both are now flagged for revision, with new editions under development. The 2019 split also renamed the standard: ISO 8601:2004 was "Data elements and interchange formats — Information interchange — Representation of dates and times"; the parts are titled "Date and time — Representations for information interchange". Note that ISO 8601 is a paid standard — RFC 3339 is the freely readable specification closest to it.
Durations and intervals
ISO 8601 also covers lengths of time, which are a different thing from the instants above. A duration starts with P and lists the parts largest-first; anything after T is a clock unit. The M before the T is months and the one after it is minutes.
P1D
one day
PT30M
thirty minutes
P1M
one month
PT1M
one minute — the T is what distinguishes it
P1Y2M3DT4H5M6S
1 year, 2 months, 3 days, 4 hours, 5 minutes, 6 seconds
P2W
two weeks — weeks do not combine with other parts
An interval joins two points with a solidus, and either end may be a duration instead of an instant: 2024-07-15T00:00Z/2024-07-16T00:00Z, 2024-07-15T00:00Z/P1D, or P1D/2024-07-16T00:00Z. Prefixing an R makes it recurring — R/P1D for an unbounded daily repeat, or R5/… for a bounded one.
Support varies more than for timestamps, so check your parser rather than assume. Weeks in particular are usually exclusive — P1W is fine, P1Y2W often is not — and RFC 3339's grammar for durations is explicitly informational, with the RFC noting ISO 8601 remains authoritative.
How to format ISO 8601 dates in code
JavaScript
new Date().toISOString()
Always UTC with milliseconds. There is no built-in way to emit a local offset — toLocaleString() is not ISO 8601, and Date.toString() is not either.
Python
datetime.now(timezone.utc).isoformat()
Not datetime.now().isoformat() — that returns naive local time with no offset, the most common ISO 8601 bug in Python. Note it emits +00:00 rather than Z.
Java
Instant.now().toString()
Always UTC with a Z. LocalDateTime.toString() omits the offset entirely; use OffsetDateTime when you need one.
Go
time.Now().Format(time.RFC3339)
Use time.RFC3339Nano if sub-second precision matters — RFC3339 truncates to whole seconds.
Frequently asked questions
What is the ISO 8601 date format?
YYYY-MM-DD — for example 2024-07-15. The fixed year-month-day order avoids the ambiguity between American (MM/DD) and European (DD/MM) conventions, and makes the dates sort correctly as plain text.
Is 2024-7-5 valid ISO 8601?
No. Month and day are always two digits, so it must be 2024-07-05. Zero-padding is what keeps every date the same width, which is what makes text sorting equal chronological sorting.
What does the T mean in an ISO timestamp?
The T separates the date from the time: 2024-07-15T14:30:00Z is 15 July 2024 at 14:30 UTC. RFC 3339's grammar requires the T, though the RFC itself notes that applications may agree to use a space for readability.
What does Z mean at the end of an ISO 8601 timestamp?
Z is a zero offset from UTC, spoken "Zulu" after the ICAO phonetic alphabet. It is the same instant as +00:00. A timestamp with no Z and no offset is a local time whose meaning depends on where it is read — the single most common ISO 8601 bug.
Which ISO 8601 should I cite — 2004, or 8601-1?
ISO 8601-1:2019 for the everyday rules. ISO 8601:2004 was withdrawn on 2019-02-25 and replaced by ISO 8601-1:2019 and ISO 8601-2:2019, so a citation to the 2004 edition names a document that is no longer current.
Is ISO 8601 the same as "ISO format date"?
Yes. "ISO format date", "ISO date format" and "ISO 8601 date" all mean dates written as YYYY-MM-DD, optionally with a time and an offset.