Guide

ISO 8601 vs Unix timestamp: differences and uses

Compare ISO 8601 date-time text with Unix timestamps, including offsets, precision, and equivalent representations of one instant.

by Tools in a Tab · Published on 2026-08-09 · Updated 2026-09-13

Short answer

ISO 8601 describes dates and times as structured text, such as 2000-01-01T00:00:00Z. A Unix timestamp represents an instant as an amount since 1970-01-01T00:00:00Z, usually in seconds or milliseconds. Both can identify the same instant, but they preserve different information and units.

One instant in several representations

These values are equivalent:

ISO/RFC 3339 UTC: 2000-01-01T00:00:00Z
ISO with offset:  1999-12-31T19:00:00-05:00
Unix seconds:     946684800
Unix milliseconds: 946684800000

Z denotes UTC. The -05:00 offset means that the displayed local clock was five hours behind; it does not identify another instant. Check all four forms with the Unix timestamp converter.

Convert ISO text to Unix time without losing milliseconds

Open the date-to-timestamp mode.
Under Date input format, choose Paste ISO 8601 with time zone.
Paste 2000-01-01T01:00:00.123+01:00 and press Convert to timestamp.
Check the UTC output 2000-01-01T00:00:00.123Z and the millisecond timestamp 946684800123. The seconds output is 946684800.123.

For the reverse check, open timestamp-to-date mode, select milliseconds, and enter 946684800123. The timestamp input accepts integers, so use milliseconds here rather than pasting fractional seconds. The resulting UTC string describes the same instant; it does not retain the original +01:00 spelling.

The ISO input supports calendar dates from year 0001 to 9999, seconds, Z or an explicit ±HH:mm offset, and optionally one to three fractional digits. It deliberately rejects date-only text, missing offsets, unknown offset -00:00, leap seconds, and extra fractional digits. These are tool limits, not a claim that every rejected form is invalid ISO 8601 or RFC 3339.

What each representation preserves

Aspect	ISO 8601/RFC 3339 text	Unix timestamp
Human readability	High	Low
Visible offset	Can include one	None
Unit	Defined by syntax	Must be agreed separately
Chronological sorting	With a normalized form and offset	Numerically
Common use	APIs, logs, configuration	Calculation, expiry, storage

A timestamp does not contain a zone name such as Europe/Madrid, and it does not reveal whether its unit is seconds or milliseconds. A string with an offset preserves the written displacement, but it does not necessarily include the full historical rules of a named time zone.

When to use each format

Use ISO text with Z or an offset in interfaces, logs, and APIs where a person should recognize the date or where the written offset is relevant. Use Unix time for numerical ordering, comparisons, expirations, and duration arithmetic under a clearly documented contract.

Do not accept seconds, milliseconds, and text interchangeably and then guess from string length. That heuristic fails for old, future, or negative values.

Common mistakes

Sending 2026-08-09T10:00:00 without Z or an offset and assuming UTC.
Multiplying by 1000 twice during a seconds-to-milliseconds conversion.
Formatting a timestamp in local time and believing the numerical instant changed.
Sorting strings with different offsets before normalizing them.
Assuming every ISO 8601 form is allowed by a more restrictive API profile.

RFC 3339 defines an Internet date-time profile based on ISO 8601. The NumericDate definition in RFC 7519 uses seconds from the Unix epoch for JWT claims. Choose one representation and make it part of the data contract.