ISO 8601 date format cheatsheet: every variant with examples
The only date format you should be storing and serialising in 2026. Every shape, the pitfalls, and the quick reference for parsing.
# The default form
2026-04-27T10:30:00Z
Year-Month-Day T Hour:Minute:Second Z.
Tseparates date from timeZ= UTC (zero offset). Pronounced "Zulu".- Everything is fixed-width and zero-padded
- Sorts correctly as a string — an ISO 8601 string sorted lexically is also sorted chronologically.
# Every form you'll see
| Form | Example | Meaning |
|----------------------------------|---------------------------------|-----------------------------------------|
| Date only | 2026-04-27 | A calendar day |
| Date + time, UTC | 2026-04-27T10:30:00Z | Instant in UTC |
| Date + time + offset | 2026-04-27T10:30:00+05:30 | Same instant, rendered in IST |
| Date + time + milliseconds | 2026-04-27T10:30:00.123Z | Millisecond-precision instant |
| Date + time + microseconds | 2026-04-27T10:30:00.123456Z | Microsecond precision |
| Ordinal date | 2026-117 | The 117th day of 2026 |
| Week date | 2026-W17-1 | Week 17, Monday |
| Basic format (no separators) | 20260427T103000Z | Compact, same meaning. Rare in APIs. |
| Duration | P1Y2M3DT4H5M6S | 1 year, 2 months, 3 days, 4:05:06 |
| Time interval | 2026-04-27/2026-05-10 | Start/end pair |
# The gotchas
# 1. Timezone designator is not optional
2026-04-27T10:30:00 (no Z, no offset) is technically "local time" — the receiver has to guess which timezone. Always include a designator. Z if UTC, +HH:MM otherwise.
<div class="callout callout-warning" role="note"><div class="callout-title">Warning</div><div class="callout-body"><p>The single most common bug: storing an ISO 8601 string without a timezone designator and later assuming it was UTC. Half the time it was local server time. The other half nobody remembers. Never store timestamps without offsets.</p></div></div>
# 2. Fractional seconds
Most parsers accept 3 (ms), 6 (µs), or 9 (ns) decimal places. A few are strict about exactly 3. Write 3 unless you specifically need more precision; 2026-04-27T10:30:00.000Z.
# 3. Leap seconds
ISO 8601 allows :60 on minutes that actually had a leap second inserted. Most libraries either skip them silently or error. Almost nothing in production cares.
# 4. Week date vs calendar date
2026-W17-1 is not the same as 2026-04-27 — week dates follow the ISO week rules (Monday-start, week 1 contains Jan 4). Sometimes they match, often they don't. Don't mix.
# 5. Negative years
-0500-01-01 = Jan 1, 500 BCE. Valid ISO 8601, but most parsers refuse. Year 0 exists in ISO 8601 (= 1 BCE) but not in the Gregorian calendar.
# Parse examples
# JavaScript
new Date("2026-04-27T10:30:00Z").toISOString();
// '2026-04-27T10:30:00.000Z' — always UTC, always 3 decimals
# Python
from datetime import datetime
datetime.fromisoformat("2026-04-27T10:30:00+00:00")
# Python 3.11+ accepts 'Z'; older versions need '+00:00'
# Go
import "time"
t, _ := time.Parse(time.RFC3339, "2026-04-27T10:30:00Z")
RFC 3339 is a slightly stricter subset of ISO 8601 — what most APIs actually use.
# PostgreSQL
SELECT '2026-04-27T10:30:00Z'::timestamptz;
Native support, stores as UTC internally, renders in the session's timezone.
# The rule
Store and serialise UTC. Display local.
- In databases:
TIMESTAMP WITH TIME ZONE(Postgres) orDATETIMEin UTC (MySQL/SQLite). - In APIs: always include
Zor+HH:MM. Never local-without-offset. - In JSON: the string form with
Zsorts correctly and parses everywhere.
# Try it
Timestamp Converter takes ISO 8601 in, gives you UTC + local + Unix timestamp out. Drop any date variant and see how your system would interpret it.
# Related reading
Frequently asked questions
›Is `2026-04-27 10:30` valid ISO 8601?
Technically no — the separator between date and time must be `T` or a space in some extended forms. Most parsers accept the space form, but strict parsers reject it. Always use `T` to be safe.
›What's the difference between `Z` and `+00:00`?
Semantically identical — both mean UTC. `Z` is shorter and what most APIs emit. Some strict parsers (old Python, some Java libs) don't accept `Z` and need `+00:00`.
›Can ISO 8601 represent 'date only' without a time?
Yes — `2026-04-27` is a valid ISO 8601 date. Just omit the time portion. Useful for birthdays, deadlines, anything that isn't tied to a specific moment.