What Is ISO 8601?
ISO 8601 is the international standard that defines how to write dates and times unambiguously as text. It’s the format your API should accept, the format your database column should store, and the format your log lines should emit — anything else leads to YYYY-MM-DD vs MM/DD/YYYY pain on the first international call.
A working example:
2026-08-27T14:35:00+09:00
That breaks into four parts:
| Part | Meaning |
|---|---|
2026-08-27 |
Date in extended format (year-month-day). |
T |
The literal separator between date and time. |
14:35:00 |
Time in 24-hour format (hours-minutes-seconds). |
+09:00 |
Time zone offset from UTC. |
Why this format wins for systems
It’s sortable as text — lexicographic order matches chronological order. 2026-08-27 sorts before 2026-08-28, and 2026-08-27T14:00:00Z sorts before 2026-08-27T14:35:00Z. You can dump a log buffer as text and search/sort it without parsing.
It’s unambiguous across cultures. 01/02/2026 is January 2nd in the US, February 1st almost everywhere else. 2026-01-02 is January 2nd everywhere.
It’s widely supported. Every mainstream language’s date library parses it; most serialise to it by default; every SQL database understands it; every modern file format uses it for timestamps.
Variants you’ll see in the wild
You don’t usually have to give the full version. The standard permits several shorthand forms:
2026— just the year2026-08— year and month2026-08-27— date only2026-08-27T14:35— date and time to the minute2026-08-27T14:35:00— date and time to the second2026-08-27T14:35:00.123— with milliseconds2026-08-27T14:35:00Z— UTC shorthand (Zmeans “+00:00”)2026-08-27T14:35:00+09:00— with explicit offset
The Z form (sometimes called “Zulu time”) is what most systems emit when they want UTC without offset clutter.
Common pitfalls
- Daylight saving. ISO 8601 stores an offset, not a time zone. A string
2026-08-27T14:35:00+09:00becomes ambiguous the day DST ends in your jurisdiction. If you mean “this wall-clock time, every day”, store a time zone identifier (Asia/Tokyo) instead of an offset. - Leap seconds. ISO 8601 does not encode them. Most civil systems ignore them.
- Negative years. ISO 8601 extends into the past with
-0001for 2 BCE, and0000for 1 BCE. Astronomers use a different convention. - No offset means local. A bare
2026-08-27is a calendar date — it has no time at all, and adding time without an offset to it is undefined.
Tools
For converting epoch timestamps to ISO 8601 strings (and back), see Epoch to DateTime — runs in the browser, no upload.
For a broader look at scheduling and time formats across the site, see the Time and Cron hub.
See also
- Cron Expression — the time-side counterpart to ISO 8601
- JSON to CSV — when your timestamp data is embedded in JSON exports
- UTC vs GMT vs EST — practical offset conversion