ISO 8601 Date Format Explained: The Only Format You Should Use

The Problem ISO 8601 Solves

Dates are one of the few things in computing where the human convention is genuinely broken. Numbers have a universal written form. Money has currency codes. But dates inherited centuries of regional habit, and those habits disagree at the most basic level: which number comes first, the day or the month. The United States writes month-first. Most of the rest of the world writes day-first. China, Japan, and Korea write year-first, which, as it happens, is the one that turned out to be correct.

The cost of that disagreement is not theoretical. It is shipping the wrong invoice because 05/06 was read as June 5th instead of May 6th. It is a cron job firing a month late. It is a spreadsheet silently reinterpreting 03/04/2026 when it crosses a border. Every one of these is a real bug that a single agreed format would have prevented.

ISO 8601, first published in 1988 and revised several times since (the current edition is ISO 8601-1:2019 and 8601-2:2019), is that agreed format. Its core rule is almost insultingly simple: write the date from the largest unit to the smallest, with the year first, and pad everything to a fixed width. YYYY-MM-DD. That ordering is the whole trick, and we will come back to why it matters so much for sorting. For now, the important thing is that it is unambiguous by construction. There is no regional dialect of ISO 8601.

The Anatomy of a Date-Time

A full ISO 8601 timestamp is three independent pieces glued together. Once you can see the seams, the whole format stops looking like a magic string and starts looking like what it is: a date, a time, and a position relative to UTC.

2026-06-06 T 13:45:30 Z
└────┬────┘ │ └───┬──┘ │
   date     │   time   └─ zone designator (here: UTC)
            └─ separator between date and time

The date is YYYY-MM-DD: a four-digit year, a two-digit month from 01 to 12, and a two-digit day from 01 to 31. Four digits for the year is deliberate. Two-digit years are how you get a Y2K, and the standard refuses to repeat that mistake. Months and days are always zero-padded, so June is 06 and never 6. That padding is not a stylistic preference; a parser that expects fixed widths will reject the short form, and so will most strict validators.

The time is hh:mm:ss on a 24-hour clock. Hours run 00 to 23, minutes and seconds 00 to 59. There is no AM/PM in ISO 8601, which is another small mercy, because "12:00 AM" is one of the most reliably misread strings in the English language. You can drop precision from the right: 13:45 is a valid time with no seconds, and 13 is a valid time with no minutes, though in practice you almost always want full hh:mm:ss.

The zone designator is what turns a local wall-clock reading into a specific instant. Without it, 2026-06-06T13:45:30 is just "quarter to two in the afternoon, somewhere." Add Z and it becomes a single point on the global timeline. We will spend real time on this part, because it is where most date bugs actually live.

Basic vs Extended Form

ISO 8601 defines two spellings of the same value. The extended form uses separators: hyphens between date parts, colons between time parts. The basic form throws the separators away to save characters.

The basic form survives in places where every byte counts or where separators are forbidden: compact log identifiers, filenames on systems that dislike colons, and the timestamps inside some binary formats. You will see 20260606T134530Z in a backup filename and it is perfectly legal. But for anything a human or an API will read, use the extended form. It is the version everyone means when they say "ISO 8601," and mixing the two within one string is not allowed: you cannot write 2026-0606.

The T and the Z

Two single letters do a lot of work in this format, and both of them confuse newcomers.

The T is a literal separator. It exists because a date and a time sitting next to each other with a space is genuinely ambiguous to a machine reading a stream of fields, so the standard nails them together with a character that can never appear inside either part. 2026-06-06T13:45:30 is one token; a parser sees the T and knows the date has ended and the time has begun. Strict ISO 8601 wants that T. RFC 3339, which we will get to, allows you to swap it for a space by mutual agreement, which is why you sometimes see 2026-06-06 13:45:30 in databases and logs. That space form is convenient for human eyes but you should not rely on a random parser accepting it.

The Z is the zone designator for UTC. It is pronounced "Zulu," from the NATO phonetic alphabet, where the UTC time zone is the "Z" zone. Z is exactly equivalent to an offset of +00:00: 2026-06-06T13:45:30Z and 2026-06-06T13:45:30+00:00 point at the same instant. The Z is shorter, it is unmistakable, and it is the form you want whenever you are storing or transmitting a moment that lives in UTC, which should be almost all of them. If you have not internalized why "store in UTC" is the golden rule, the UTC and time zones guide makes that case in full.

Offsets: Z, +00:00, and the One That Means "Unknown"

When a timestamp is not in UTC, ISO 8601 lets you attach an explicit offset from UTC in the form ±hh:mm. A timestamp from an office in Karachi at the same instant as our example would read 2026-06-06T18:45:30+05:00: the same moment, displayed five hours ahead, with the offset spelled out so no information is lost. You can convert it back to UTC by subtracting the offset, and you get our original 13:45:30Z.

This is the single most useful property of an ISO 8601 timestamp with an offset: it is self-describing. Anyone, with no database and no time zone library, can compute the underlying UTC instant from the text alone. That is why it is the right format for logs, wire protocols, and any place two systems need to agree on a moment without sharing a configuration.

One subtlety is worth memorizing because it is genuinely useful. An offset is not a time zone. +05:00 tells you the displacement from UTC at this one instant; it tells you nothing about daylight saving rules, and it will be wrong six months from now for any zone that observes DST. The offset is a snapshot; the zone is the rulebook that produces snapshots. If you need to store the rules (for a recurring future event, say), store the IANA zone name like Asia/Karachi alongside the timestamp, not just the offset. The time zones guide goes deep on exactly this distinction.

There is also a deliberately strange offset: -00:00. In RFC 3339 this is not the same as Z or +00:00. A trailing -00:00 means "this timestamp is in UTC, but the offset of the original local time is unknown or irrelevant." It is a way of saying "I normalized this to UTC but I have thrown away where it came from." Most systems never need it, but if you ever see -00:00 in the wild, that is what its author was trying to tell you.

Fractional Seconds and the Comma

Sub-second precision is appended to the seconds field as a decimal fraction: 2026-06-06T13:45:30.250Z is 250 milliseconds past the half-minute. You can use as many digits as your precision warrants: three for milliseconds, six for microseconds, nine for nanoseconds. There is no fixed limit in the standard; the limit is whatever your data type and your parser agree on.

Here is the historical trap. The original ISO 8601 text named the comma as the preferred decimal separator and the period as merely "permitted." That is a European typographic convention, and it means 13:45:30,250 is technically valid ISO 8601. The problem is that almost nothing in the software world accepts the comma. JSON does not, JavaScript does not, virtually every API does not, and RFC 3339 settled the matter by mandating the period. So while the comma is legal on paper, the only safe choice in practice is the dot. Write 30.250, never 30,250, and you will never have a parser reject your timestamp over punctuation.

Durations and Intervals

Most people only ever meet the date-time half of ISO 8601, but the standard also describes spans of time, and these forms are quietly everywhere once you learn to spot them.

A duration is a length of time with no fixed start. It begins with the letter P (for "period") and lists components from largest to smallest, with a T separating the date parts from the time parts:

P3Y6M4DT12H30M5S   →  3 years, 6 months, 4 days, 12 hours, 30 minutes, 5 seconds
P1D                →  1 day
PT1H               →  1 hour          (note the T: hours are a time part)
PT0S               →  zero duration
P2W                →  2 weeks         (weeks are their own form, used alone)

The T matters more than it looks. P1M is one month; PT1M is one minute. The same letter M means month before the T and minute after it, and the only thing that disambiguates them is which side of the T they sit on. This is exactly the kind of detail that produces a bug six months after deploy, so it is worth burning into memory.

An interval is a span with actual endpoints, written as two values joined by a slash. You can express it three ways: start and end, start and duration, or duration and end.

2026-06-01T00:00Z/2026-06-08T00:00Z    →  a specific week, both ends given
2026-06-01T00:00Z/P7D                  →  start, then "plus seven days"
P7D/2026-06-08T00:00Z                  →  "seven days up to" the end
R5/2026-06-01T00:00Z/P1D               →  repeat: 5 daily intervals from this start

That last form, the repeating interval with the R prefix, is how some scheduling and calendaring systems describe recurrence compactly. You will not write these by hand often, but when an API hands you P30D as a billing period or PT15M as a token lifetime, you will know exactly what you are looking at.

Week Dates and Ordinal Dates

ISO 8601 can name a day in two ways that have nothing to do with calendar months, and both trip people up because they look like typos at first.

An ordinal date is the year plus the day-of-year, from 001 to 365 (or 366 in a leap year): 2026-157 is the 157th day of 2026, which happens to be June 6th. This is handy when the gap between two dates matters more than the calendar label, and it shows up in aviation, some scientific data, and older mainframe systems where it is called a "Julian date" (a name that is technically wrong but stubbornly common).

A week date names the ISO week and weekday: 2026-W23-6 is the 6th day of the 23rd week of 2026. The weekday runs 1 for Monday through 7 for Sunday, because ISO 8601 puts Monday at the start of the week, not Sunday. The week-numbering rule has one gotcha that causes real confusion: ISO week 1 is the week containing the year's first Thursday (equivalently, the week containing January 4th). The practical consequence is that the first few days of January can belong to week 52 or 53 of the previous year, and the last days of December can belong to week 1 of the next year. If you build dashboards that group by ISO week, test the year boundary explicitly, because 2027-W01 may start in December 2026.

ISO 8601 vs RFC 3339

If you work with web APIs, the format you actually use every day is not quite ISO 8601. It is RFC 3339, a profile of ISO 8601 written by the IETF specifically for internet timestamps. RFC 3339 takes the sprawling, flexible ISO 8601 standard and pins it down to a single strict, easy-to-parse shape.

The relationship is best understood as "RFC 3339 is a stricter, smaller ISO 8601." Almost every valid RFC 3339 timestamp is valid ISO 8601, but the reverse is far from true. Here is what RFC 3339 throws away:

The takeaway is practical: when you design an API, specify RFC 3339, not "ISO 8601." Saying ISO 8601 invites clients to send you week dates, durations, offset-free local times, and comma decimals, and now your parser has to handle the entire standard. Saying RFC 3339 means every timestamp is a full date-time with an explicit offset and a period for fractions, which is a shape you can validate with a single regular expression. This is the same advice the API design post gives, and it is the rule behind the date-time format keyword in JSON Schema, which validates against RFC 3339 rather than the looser parent standard.

Why YYYY-MM-DD Beats Every Other Format

There is one property of ISO 8601 that, once you have felt it, makes you unable to tolerate any other date format: lexical order equals chronological order. Because the format runs from the largest unit to the smallest, sorting ISO 8601 strings alphabetically sorts them by time. No date parsing required.

# These strings sort correctly with a plain text sort:
2026-06-06T08:00:00Z
2026-06-06T13:45:30Z
2026-06-07T09:15:00Z
2026-12-01T00:00:00Z

# A regional format does not. Sorted as text, this is nonsense:
01/12/2026
06/06/2026
06/07/2026

This is not a parlor trick. It is the reason log files timestamped in ISO 8601 are trivially sortable, the reason database indexes on ISO date columns behave predictably, and the reason filenames like backup-2026-06-06.tar.gz line up in chronological order in any file browser on Earth. You get sorting for free, in any language, in any shell, with no library, simply because the digits were written in the right order. Every other date format makes you parse before you can compare. This one does not.

Two conditions keep the magic working. The strings must be zero-padded (so 06 not 6, otherwise 10 sorts before 9), and they must share an offset. A list mixing +00:00 and +05:00 values will sort by the text, not the true instant. The clean solution is the one you already wanted: normalize everything to UTC with a Z before you store or sort it.

Valid vs Invalid: A Reference Table

A quick reference you can scan when something will not parse. "Valid" here means valid extended ISO 8601; the notes call out where RFC 3339 is stricter.

How Each Language Handles It

The good news for 2026 is that ISO 8601 support is now table stakes in every major standard library. You rarely need a third-party date parser anymore. Here is the one-liner for producing and consuming an ISO timestamp in the languages you are most likely to reach for.

// JavaScript — always emits UTC with a Z and milliseconds
new Date().toISOString();           // "2026-06-06T13:45:30.250Z"
new Date("2026-06-06T13:45:30Z");   // parses back to a Date

# Python — fromisoformat handles Z natively since 3.11
from datetime import datetime, timezone
datetime.now(timezone.utc).isoformat()        # "2026-06-06T13:45:30.250+00:00"
datetime.fromisoformat("2026-06-06T13:45:30Z") # parse (3.11+)

// Go — the layout constant IS the format
import "time"
time.Now().UTC().Format(time.RFC3339)            // "2026-06-06T13:45:30Z"
time.Parse(time.RFC3339, "2026-06-06T13:45:30Z") // parse

// Java — java.time speaks ISO 8601 by default
import java.time.Instant;
Instant.now().toString();                  // "2026-06-06T13:45:30.250Z"
Instant.parse("2026-06-06T13:45:30Z");     // parse

A few notes that save time. JavaScript's toISOString() always returns UTC with a Z and always includes milliseconds, which is exactly what you want for storage and transport. Python's fromisoformat only learned to accept the Z suffix in 3.11; on older versions you have to replace Z with +00:00 first, which is the single most common Python date-parsing question on the internet. Go is the odd one out: instead of YYYY-MM-DD tokens it formats with a specific reference time (Mon Jan 2 15:04:05 MST 2006), but the built-in time.RFC3339 constant means you almost never write that layout by hand for ISO output.

The Gotchas That Still Bite

1. The JavaScript date-only / date-time split

This one has burned nearly everyone. In JavaScript, new Date("2026-06-06") (date only) is parsed as UTC midnight. But new Date("2026-06-06T00:00:00") (date-time with no offset) is parsed as local midnight. The same calendar day, one with a time and one without, lands on two different instants for anyone not sitting in UTC. The fix is to never rely on offset-free strings: always include a Z or an explicit offset so the parse is deterministic.

2. Treating an offset like a time zone

Storing +05:00 and assuming you have captured the user's time zone is a trap. The offset is correct only for that instant. Schedule a recurring 9 a.m. meeting using a stored offset and it will drift by an hour when daylight saving flips. Store the IANA zone name for anything that recurs in the future; store the UTC instant plus offset for anything that already happened. The time zones guide walks through the future-event case in detail.

3. The comma decimal separator

A timestamp like 13:45:30,250 is valid ISO 8601 but will be rejected by almost every parser you meet. If you are generating timestamps in a locale that defaults to comma decimals, force the period. This bites teams that format dates through a locale-aware library without overriding the separator.

4. Double-converting time zones

A timestamp already carrying Z is in UTC. Running it through "convert to UTC" a second time, or applying the server's local offset to a value that is already absolute, shifts it by hours. The rule that prevents this: parse into a real instant type as early as possible, keep it in UTC internally, and only apply a zone at the very end when you display it. If you want the deeper version of the epoch-versus-text model, the Unix timestamps explainer covers the numeric side that sits underneath ISO 8601.

5. Two-digit years and ambiguous truncation

ISO 8601 permits some truncated and expanded year forms, but two-digit years are a relic that strict profiles reject outright, and for good reason. If a system hands you 26-06-06, it is not giving you ISO 8601, it is giving you a guessing game. Always demand the full four-digit year.

Common Questions

Is ISO 8601 the same as RFC 3339?

No, but they are close relatives. RFC 3339 is a strict profile of ISO 8601 built for internet timestamps. Almost every RFC 3339 value is valid ISO 8601, but ISO 8601 also allows week dates, ordinal dates, durations, the basic no-separator form, and offset-free times that RFC 3339 forbids. For APIs, specify RFC 3339; it is the smaller, easier-to-validate subset.

What does the Z at the end mean?

It means the time is in UTC. Z ("Zulu") is exactly equivalent to an offset of +00:00. 2026-06-06T13:45:30Z and 2026-06-06T13:45:30+00:00 are the same instant; the Z is just the shorter spelling.

Should I store dates as ISO 8601 strings or Unix timestamps?

For external APIs and logs, ISO 8601 (specifically RFC 3339) wins because it is human-readable, self-describing, and sortable as text. For internal storage where bytes and arithmetic matter, a numeric Unix timestamp is compact and trivially comparable. Many systems use both: ISO strings on the wire, integers in the hot path. The Unix timestamps post covers the trade-off in depth.

Why does ISO 8601 start the week on Monday?

Because the standard defines it that way: weekday 1 is Monday and 7 is Sunday. This differs from the US convention of Sunday-first, which is a frequent source of off-by-one bugs when grouping data by week. If you use ISO week dates, also remember that week 1 is the week containing the first Thursday of the year, so early January can fall in the previous year's final week.

Can I use a space instead of the T?

RFC 3339 permits it "by mutual agreement," which is why databases often display 2026-06-06 13:45:30. But strict ISO 8601 wants the T, and many parsers reject the space. For anything machine-read, keep the T. Use the space only inside systems where you control both ends.

Wrapping Up

ISO 8601 is one of those standards that looks fussy until you have been bitten by the alternative, and then it looks like a gift. The whole thing reduces to a few rules worth keeping in your head: write dates largest unit first as YYYY-MM-DD, use a 24-hour clock, glue date and time with a T, always attach a zone (a Z if you have done the sensible thing and normalized to UTC), and use a period for fractional seconds. Follow those and your timestamps sort themselves, parse in every language, and never start an argument about whether 03/04 is March or April.

For day-to-day work, lean on RFC 3339 rather than the full standard. It keeps the useful 95% and drops the parts that make parsers complicated. Reserve the week dates, ordinal dates, durations, and intervals for the specific cases that need them, and reach for them knowing they exist rather than reinventing them.

If you want to move between formats while you work, the time zone converter and the Unix timestamp converter on this site turn ISO 8601 strings into epoch values and back, in your browser, with nothing uploaded. And for the two layers on either side of this one, the Unix timestamps explainer covers the numeric representation underneath, while the UTC and time zones guide covers the zone rules above it. Together the three are the whole story of how a moment becomes text and back again.