ISO 8601 Date Format Explained

An ISO 8601 date looks like 2026-09-26: four-digit year, two-digit month, two-digit day, largest unit first, separated by hyphens. A full timestamp adds a T, the time and an offset from UTC: 2026-09-26T14:05:00+05:30, or 2026-09-26T08:35:00Z where Z means UTC itself. That is the form almost everyone means by "ISO format", and it is the one to use for APIs, logs and file names. The standard itself is much larger. It also defines week dates, ordinal dates, a compact "basic" format without separators, reduced precision, decimal fractions, durations and intervals, and most of those variants are not accepted by most parsers.

#Why the format works

Three design decisions make ISO 8601 the right default for machine-readable dates:

• Largest unit first. 2026-09-26 cannot be misread as 9 February or 26 September depending on the reader's country, which 09/02/2026 can.
• Fixed width, zero padded. Strings sort lexicographically in chronological order, provided they share the same offset. That is why 2026-09-26_backup.sql beats 26-9-2026_backup.sql as a file name.
• Explicit offset. A timestamp with Z or +05:30 identifies one instant. Without it, the reader has to guess the zone.

#Anatomy of a timestamp

2026-09-26T14:05:00.123+05:30
│    │  │ ││  │  │ │   └───── UTC offset: +hh:mm, or Z for UTC
│    │  │ ││  │  │ └───────── decimal fraction of the second (. or ,)
│    │  │ ││  │  └─────────── second, 00–59 (60 during a leap second)
│    │  │ ││  └────────────── minute, 00–59
│    │  │ │└───────────────── hour, 00–23
│    │  │ └────────────────── T separates date from time
│    │  └──────────────────── day, 01–31
│    └─────────────────────── month, 01–12
└──────────────────────────── year, four digits (0000–9999)

Enter this timestamp into the Date Formatter and it will render it in any pattern and any zone:

2026-09-26T14:05:00+05:30

With the default pattern yyyy-MM-dd'T'HH:mm:ssxxx, the output depends on the zone you choose, which is the point: the instant is fixed and only its representation changes.

All three strings denote the same moment. Note that +00:00 and Z are equivalent; many serialisers emit Z, and the Date Formatter's pattern token xxx emits +00:00. Use XXX if you want Z.

#Every variant in one table

The same date written three ways: 2026-09-26 is Saturday of ISO week 39, and the 269th day of the year. The Date Formatter produces the week form with the pattern RRRR-'W'II-i (output 2026-W39-6) and the ordinal form with yyyy-DDD (output 2026-269).

#Week dates and the week-numbering year

ISO weeks start on Monday, and week 01 is the week containing the year's first Thursday (equivalently, the week containing 4 January). So the first days of January can belong to the last week of the previous year, and the last days of December to week 01 of the next. That "week-numbering year" is a separate field from the calendar year, and confusing the two is the cause of the YYYY formatting bug covered in date format patterns. Years with 53 ISO weeks are those that start on a Thursday, or leap years that start on a Wednesday; 2026 is one of them.

#Durations

A duration is written P, then date components, then T, then time components:

P1Y2M10DT2H30M15S   1 year, 2 months, 10 days, 2 hours, 30 minutes, 15 seconds
P2W                 2 weeks
PT36H               36 hours
P1M                 1 month
PT1M                1 minute

The T is what distinguishes months from minutes, so P1M and PT1M differ by a factor of about 43,800. Only the smallest component may carry a fraction (PT0.5S, P1.5D). Try one in the Duration Formatter:

P1DT2H30M15S

It reads 1 day, 2 hours, 30 minutes, 15 seconds and totals 95,415 seconds. Two warnings apply to every duration library:

• Years and months have no fixed length. P1M added to 31 January gives a different number of days than added to 1 February. Converting to seconds requires an average (the Duration Formatter uses 365.2425 days per year and 30.44 days per month, and says so).
• Days are not always 24 hours. Across a daylight-saving transition, P1D and PT24H land on different wall-clock times. Java models this split explicitly: Period holds years, months and days; Duration holds exact seconds, and Duration.parse("P1DT2H30M15S") prints back as PT26H30M15S, while Duration.parse("P1M") throws.

#ISO 8601 vs RFC 3339

RFC 3339 is a profile of ISO 8601 for internet protocols. It picks one unambiguous subset and adds two small extensions. JSON Schema's date-time format, most API style guides and many log formats reference RFC 3339, not ISO 8601.

The practical intersection, YYYY-MM-DDTHH:MM:SS[.fff](Z|±HH:MM), is valid under both. Emit exactly that and you will not need to know which one a consumer implements.

#How languages parse it

The first two rows are the most common JavaScript date bug. The ECMAScript specification says a date-only ISO string is UTC but a date-time without an offset is local time. In India, new Date("2026-09-26") is 05:30 local time on the 26th, while new Date("2026-09-26T00:00") is 18:30 UTC on the 25th. In the Americas, the date-only form displays as the previous day. If you mean a calendar date with no time, keep it as a string or a date-only type; if you mean an instant, include the offset.

#Mistakes that produce valid-looking but wrong strings

• A literal Z on a local time. Patterns such as yyyy-MM-dd'T'HH:mm:ss'Z' print the letter Z whatever the value's zone is. If the value is local time, the string claims to be UTC and is off by the local offset. Use an offset token (XXX in date-fns and Java, %z in Python) or convert to UTC first. JavaScript's toISOString() is safe because it always converts to UTC.
• Missing zero padding. 2026-9-26 is not ISO 8601, will not sort correctly, and is rejected by strict parsers.
• An offset is not a time zone. +05:30 records the offset at one instant. It says nothing about daylight-saving rules, so it cannot tell you the offset of the same wall-clock time next month. For future events in local time (a meeting at 09:00 in New York every Monday), store the local time and the IANA zone name, and compute the offset when needed.
• Two-digit years and implied centuries. ISO 8601 no longer allows two-digit years in its general forms; always write four digits.

#Rules for using ISO 8601 in systems

1. Serialise instants as RFC 3339 with an explicit offset, preferably Z for stored and logged values.
2. Use calendar dates (2026-09-26) for date-only values such as birthdays and due dates, and never attach a time or zone to them.
3. Include fractional seconds only when you need them, and document the precision; JavaScript keeps milliseconds, Python microseconds, Java and PostgreSQL up to nanoseconds and microseconds respectively.
4. Do not assume other variants will parse. Week dates, ordinal dates, basic format and comma fractions are valid ISO 8601 and are rejected by common parsers.
5. For stored numeric instants, see Unix timestamps; to convert an ISO string to epoch seconds, use the Unix Timestamp Converter.