ISO 8601 Date Format Explained: What It Looks Like and How to Use It

ISO 8601 is the international standard for writing dates and times as text, and it is the format you see in API responses, database dumps and log lines: 2026-08-15T14:30:00Z. It exists because dates in natural language are ambiguous - 08/15/2026 means August 15 in the United States and 8 December in much of Europe - while a single ordered format removes the guesswork. The Wikipedia ISO 8601 reference lists every permitted form.

What does an ISO 8601 string look like?

2026-08-15              date only
14:30:00                time only
2026-08-15T14:30:00     date and time, local interpretation
2026-08-15T14:30:00Z    date and time, UTC
2026-08-15T14:30:00+02:00    date and time, with a UTC offset

The rules are fixed: the year comes first with four digits, month and day follow with two digits each and dashes between, the T separates date from time, and the time uses a 24-hour clock. A trailing Z marks UTC, and a signed offset such as +02:00 replaces the Z when the value is not at UTC. Every part is zero-padded so that fixed-width parsing works.

Why does the order matter?

Because the most significant part comes first, ISO 8601 strings sort correctly as plain text. Sorting 2026-08-15 and 2026-08-16 alphabetically puts them in date order, and the same holds for full timestamps down to the seconds. That property is why logs, filesystems and databases keep timestamps in this shape: a simple string sort gives chronological order with no parsing at all. The Unix timestamp has the same property as a number.

What do the T and the Z mean?

The T is a separator that says the date has ended and the time is beginning; it is a single character so the string stays compact and unambiguous. The Z is the timezone marker: Z is shorthand for Zulu, the radio-telephony name for UTC, and it declares that the time is expressed at UTC. When a value comes from another zone, the offset appears instead, as in +02:00 for a place two hours east of UTC. Both forms name the same absolute instant; only the representation differs.

Which form should you store?

Store the instant, not a wall-clock reading. The two storage-friendly forms are a Unix timestamp in seconds and an ISO 8601 string ending in Z. An offset like +02:00 describes a timezone at one moment, and because zones switch between standard and daylight time, an offset stored today can describe the wrong hour tomorrow. Put the offset back on only at the display boundary, using the timezone of the viewer. This mirrors the rule in the epoch time guide: keep the instant absolute, format locally.

How do you parse ISO 8601 in code?

// JavaScript - ISO strings with offsets parse natively
new Date('2026-08-15T14:30:00Z').toISOString();

# Python - fromisoformat handles ISO 8601 in 3.11+
import datetime
datetime.datetime.fromisoformat('2026-08-15T14:30:00+02:00')

Both languages parse the standard form without a library. The one habit to keep is including the Z or the offset in the string you parse; a timestamp with neither is interpreted in the local timezone of the machine, which is almost never what a stored value means.

When do you see timezone offsets in practice?

Offsets appear at API boundaries where a service reports a local event, and in log lines that want to show the server zone. Reading one is arithmetic: +02:00 means the clock is two hours ahead of UTC, so the same instant is 12:30 UTC when the string says 14:30. The offset only fixes that single instant; to reconstruct the zone rules for the next daylight saving switch you need an IANA name such as Europe/Paris, not an offset. For comparing or storing, normalize everything to UTC first.

How do you convert between ISO 8601 and Unix time?

The two formats are the same instant in different clothes. JavaScript parses an ISO string to milliseconds and formats a number back with toISOString, which always emits the Z form. Python does the same with fromisoformat and isoformat. The Unix Timestamp Converter shows both representations of a value at once, which is the fastest way to verify a conversion you are about to trust in code.