ISO 8601 is the international standard for writing dates and times as text, and its core rule is to order the fields from largest to smallest and zero-pad each one, giving forms like 2026-09-02 for a date and 2026-09-02T14:30:00Z for a moment in UTC. The whole point is to remove ambiguity: the same string means the same thing to a reader in any country and to any parser in any language. This article walks through the date form, the time form, how they combine with the T separator, how time zones are expressed with Z and numeric offsets, and the less familiar parts like week dates and durations.
Why does ISO 8601 exist?
ISO 8601 exists because national date conventions contradict each other, and a shared, unambiguous format is the only way machines and people across borders can agree on what a date means. The string 03/09/2026 is the 3rd of September to most of the world and the 9th of March in the United States. There is no way to tell which is meant from the value alone. ISO 8601 fixes this by mandating a single field order, big-endian, from year down to second, with fixed widths and separators. Once everyone writes 2026-09-03, the ambiguity is gone. A second motivation is sortability: because the fields descend in significance and each is zero-padded, the text sorts chronologically without any date parsing, which is enormously useful for filenames, log lines, and database keys.
How is a date written?
The calendar date is written year, month, day, each field separated by a hyphen and zero-padded to its full width: YYYY-MM-DD. So 2 September 2026 is 2026-09-02, with a leading zero on the month and the day. The year is four digits, the month is 01 to 12, and the day is 01 to 31. The extended format shown here uses hyphens; a basic format omits them, giving 20260902, which you sometimes see in compact filenames. The zero-padding is not optional in ISO 8601 and it is what makes string sorting work, because 2026-09-02 and 2026-11-02 compare correctly character by character only when the month is always two digits.
How is a time written?
The time of day is written hour, minute, second in 24-hour form, colon-separated and zero-padded: hh:mm:ss. Half past two in the afternoon is 14:30:00. Hours run 00 through 23, so there is no AM or PM. You may drop trailing fields when you do not need them, so 14:30 is a valid time to the minute, and you may add a decimal fraction of a second with a dot, as in 14:30:00.250 for 250 milliseconds. The table below shows the pieces of a full timestamp:
| Part | Example | Meaning |
|---|---|---|
| Date | 2026-09-02 |
2 September 2026 |
| Separator | T |
Date ends, time begins |
| Time | 14:30:00 |
2:30 PM, 24-hour clock |
| Zone | Z |
UTC (zero offset) |
What does the T separator do?
The uppercase T is a literal character that separates the date from the time in the combined form, so the reader and the parser always know where one ends and the other starts. A full date-time looks like 2026-09-02T14:30:00. Without the T you would have to guess whether a stray number belongs to the day or the hour; the separator removes that guess. In casual writing people often replace the T with a space, as in 2026-09-02 14:30:00, and many parsers accept it, but the strict standard uses T. When you need a value that survives being passed between systems untouched, keep the T. Converting between this human-readable form and a raw epoch number is exactly what a timestamp converter does, and doing it in the browser means you can check a value without sending it to a server.
How are time zones expressed?
A time zone is expressed as a suffix that is either the letter Z for UTC or a signed offset in hours and minutes, and without one of these a timestamp does not name a single global instant. The letter Z, spoken as “Zulu”, means an offset of zero, so 2026-09-02T14:30:00Z is 14:30 in UTC. A numeric offset states how far ahead of or behind UTC the local time is, written +hh:mm or -hh:mm. The same instant as the Z example above, viewed in a zone five and a half hours ahead, is written 2026-09-02T20:00:00+05:30. These two strings denote the identical moment; they differ only in the local wall clock they present it on.
The distinction that trips people up is between a timestamp with a zone and one without. A value like 2026-09-02T14:30:00, bare, is a local or floating time: it says “half past two” but not where, so it is not a fixed point on the world timeline. Attach Z or an offset and it becomes an instant. When you store the moment something happened, always include the zone, and UTC (Z) is the usual choice because it has no daylight-saving shifts.
What about week dates and ordinal dates?
ISO 8601 also defines a week-numbering system and a day-of-year system, both less common but worth recognising. A week date is written with a W, as in 2026-W36-3, meaning the third day of the 36th week of 2026. ISO weeks start on Monday, and week 1 is the week containing the year’s first Thursday, which means early January days can belong to the last week of the previous ISO year. An ordinal date names the day by its position in the year: 2026-245 is the 245th day of 2026. Both forms are legal ISO 8601 and sort correctly for the same reason the calendar form does, but the calendar date remains the one you will use most.
How are durations and intervals written?
A duration, meaning a length of time rather than a point, is written starting with the letter P for “period”, with a T introducing any time-of-day components. The pattern is PnYnMnDTnHnMnS. So P1Y2M10DT2H30M is one year, two months, ten days, two hours, and thirty minutes. Note the T’s job here: it disambiguates the two uses of M, which means months before the T and minutes after it. P30D is thirty days; PT15M is fifteen minutes. An interval joins two points with a slash, as in 2026-09-02T00:00:00Z/2026-09-03T00:00:00Z for a full day, and you can also combine a start with a duration, such as 2026-09-02T00:00:00Z/P1D. These forms show up in scheduling, billing periods, and APIs that describe ranges.
How do I read and convert an ISO 8601 value?
Read an ISO 8601 value left to right, largest unit first, and treat the suffix as the deciding factor for whether it is a fixed instant. Confirm the field order (year, month, day), check for the T, and look at the end for Z or an offset before you decide what moment it names. The most common real-world confusion is assuming a zone-less value is UTC, or reading a +05:30 offset as if it changed the instant rather than just its presentation. When a timestamp looks wrong, the quickest check is to convert it to a plain epoch number and back, which collapses the offset arithmetic into a single comparable integer. A client-side timestamp converter does this without transmitting the value anywhere, so you can safely paste a timestamp from a log or a database, see the instant it represents in UTC and local time, and verify that two differently-offset strings really are the same moment.
ISO 8601 rewards a small amount of memorisation with a large amount of clarity. Keep three ideas in mind: fields run big-endian and zero-padded so text sorts like time, the T separates date from time, and the suffix (Z or a numeric offset) is what turns a wall-clock reading into a worldwide instant. With those, you can write, read, and trust dates that mean the same thing to everyone who receives them.