What Is the ISO 8601 Date and Time Format?

#The practical answer: use an RFC 3339-shaped string

When an API asks for an “ISO 8601 timestamp,” the safest output is usually this:

2024-03-15T14:30:00.123Z

It shows fields in descending order, fixed width numbers, seconds, and the UTC relationship. That combination is human-readable, sortable under the right circumstances, and accepted by the date-time parsers most likely to be encountered by developers.

ISO 8601 itself is much larger than this one pattern. It supports calendar dates, times, week dates, ordinal dates, durations, intervals and recurring intervals. RFC 3339 narrows those choices to a predictable Internet timestamp. It matters when “valid ISO” and “accepted by this API” are not the same set.

#Read the common timestamp from left to right

Break 2024-03-15T14:30:00.123Z into these components:

Component	Value	Meaning
Year	2024	four-digit calendar year
Month	03	March, zero-padded
Day	15	day of the month, zero-padded
Separator	T	separates date and time
Time	14:30:00	24-hour local clock reading
Fraction	.123	optional fractional seconds
Offset	Z	UTC, equivalent to +00:00

The extended punctuation is not decoration. Hyphens, colons, T, and the offset make the contract obvious and prevent locale conventions from changing the interpretation.

These strings represent the same instant:

2024-03-15T14:30:00Z
2024-03-15T09:30:00-05:00
2024-03-15T15:30:00+01:00

When comparing timestamps as plain text, first normalize them to the same offset and fractional precision. A mixed set of Z, positive offsets, and different fraction lengths does not automatically sort in chronological order merely because every value resembles ISO 8601.

#An offset identifies an instant, not a timezone

-05:00 says that the displayed clock is five hours behind UTC at this instant. It does not say why, where the clock is located, or whether the offset will change next month.

An IANA timezone such as America/New_York is a rule set. It contains historical and scheduled offset transitions, including daylight-saving changes. This difference determines what you need to store:

Requirement	Store
Record when an event occurred	instant, usually UTC or an offset timestamp
Display an event in a user's zone	instant plus the user's IANA timezone
Keep a meeting at 9 a.m. local after DST changes	local date/time plus IANA timezone and a disambiguation policy
Preserve the offset originally received	original string or an explicit offset field

Timezone abbreviations such as EST, CST, or IST are poor interchange values because they are ambiguous and do not carry a transition history.

#ISO 8601 and RFC 3339 solve different-sized problems

RFC 3339 intentionally leaves out many ISO 8601 alternatives so Internet parsers have fewer branches to implement.

Feature	ISO 8601 family	RFC 3339 profile
Extended calendar date	2024-03-15	required form
Basic form	20240315T143000Z	not allowed
UTC relationship	may be omitted in some representations	offset or Z required
Week and ordinal dates	supported	not supported
Fractional seconds	supported	supported after seconds
Date/time separator	multiple ISO contexts exist	grammar uses T
Primary use	broad information interchange	Internet protocol timestamps

The RFC permits lower-case t and z in its base grammar but recommends upper-case output. It also notes that a specification may allow a space in place of T. That note is not a promise that an arbitrary RFC 3339 parser will accept the space. Generate the conservative form.

#RFC 9557 adds timezone information without replacing the offset

RFC 9557 defines the Internet Extended Date/Time Format (IXDTF). Its most visible feature is a bracketed timezone suffix:

2024-03-15T14:30:00+01:00[Europe/Paris]

The timestamp is still attached to an instant by the numeric offset. (The name in brackets specifies the rules needed for operations such as "one day later in Paris".) Those two can disagree in case of timezone rule changes, or when a producer uses stale data. A parser needs an inconsistency policy, not just to silently trust whatever field it reads first.

RFC 9557 also supports a critical marker:

2024-03-15T14:30:00+01:00[!Europe/Paris]

The ! tells a recipient that understanding the annotation is required. Do not arbitrarily strip bracketed data if the annotation is identified as critical.

#ISO 8601 also represents dates, durations, and intervals

Not every ISO 8601 value is an instant:

Kind	Example	Meaning
Calendar date	2024-03-15	a date without a time or zone
Ordinal date	2024-075	the 75th day of 2024
Week date	2024-W11-5	Friday in ISO week 11
Duration	P3DT4H30M	three days, four hours, thirty minutes
Interval	2024-03-01/2024-04-01	start and end
Start plus duration	2024-03-01/P1M	one calendar month from the start
Repeating interval	R3/2024-03-01/P1D	three daily intervals

You cannot always express a calendar duration in a fixed number of seconds. P1M depends on the starting date, and P1D in a timezone can span 23 or 25 elapsed hours across a daylight-saving transition. Choose an instant duration or a calendar duration deliberately.

#Emit and parse the narrow form in code

JavaScript emits a UTC string with millisecond precision:

const nowIso = new Date().toISOString();

const input = "2024-03-15T14:30:00Z";
const parsed = new Date(input);

if (Number.isNaN(parsed.getTime())) {
  throw new RangeError("Invalid timestamp");
}

console.log(parsed.toISOString());
// "2024-03-15T14:30:00.000Z"

Python can preserve an explicit offset and normalize it to UTC:

from datetime import datetime, timezone

value = datetime.fromisoformat("2024-03-15T09:30:00-05:00")
utc_value = value.astimezone(timezone.utc)

print(utc_value.isoformat().replace("+00:00", "Z"))
# 2024-03-15T14:30:00Z

Coverage of grammar does not mean the same thing for library names. Try the exact formats your boundary accepts: * Expanded years * Leap second notation * Reduced precision * Bracketed annotations * Fractional precision beyond milliseconds

#Common interoperability failures

• Omitting Z or an offset when the value is meant to identify an instant
• Accepting a local time and silently interpreting it in the server's timezone
• Assuming +00:00, Z, and RFC 9557's updated -00:00 semantics are interchangeable in every contract
• Treating an offset as a permanent IANA timezone
• Emitting +0000 when the receiver requires the RFC 3339 colon form +00:00
• Comparing strings with different offsets or fractional widths as though lexical order were chronological order
• Truncating fractional seconds without documenting whether values are rounded or truncated
• Claiming broad “ISO 8601 support” when the implementation only accepts RFC 3339 timestamps

The useful API contract is not “send ISO.” It is closer to: “send an RFC 3339 timestamp with upper-case T and Z, UTC only, and at most three fractional digits.” Specific contracts are easier to test and much harder to misunderstand.

#Official references and related reading

• ISO 8601-1:2019 basic rules
• ISO 8601-2:2019 extensions
• RFC 3339 Internet timestamps
• RFC 9557 Internet Extended Date/Time Format
• Unix Timestamp Formats
• Unix Time to Date
• JavaScript Date and Unix Timestamps