ISO 8601 vs Unix Timestamps: Which Format to Use

Two formats dominate machine-readable time:

• ISO 8601 — a string such as 2026-08-16T12:00:00Z
• Unix timestamp — an integer such as 1786874400 (seconds) or 1786874400000 (milliseconds)

They can describe the same instant. They serve different jobs. Confusing them causes silent bugs: wrong timezone display, off-by-1000 errors, and ambiguous sorting.

Convert either way with the Epoch Converter or Unix Timestamp Converter.

What each format is

Unix time is the count of seconds (POSIX) or milliseconds (common in JavaScript) since the Unix epoch: 1 January 1970 00:00:00 UTC. It is timezone-agnostic as a number: the integer is always UTC-based. Local display is a separate step.

ISO 8601 is a calendar representation with optional time and offset. Examples:

• 2026-08-16 — date only
• 2026-08-16T12:00:00Z — UTC instant (Z = offset zero)
• 2026-08-16T17:30:00+05:30 — same wall idea with an explicit offset (IST)

A well-formed ISO string can be both human-readable and parseable. A Unix integer is compact and easy to compare, but opaque without a converter.

Side-by-side

Concern	ISO 8601	Unix timestamp
Human readable	Yes	No
Sortable as text / number	Lexical if zero-padded + consistent form	Numeric sort is natural
Storage size	Larger strings	Compact integers
Timezone in value	Offset or Z can be embedded	Always epoch/UTC; zone is display-only
Ambiguity risk	Incomplete strings (2026-08-16 has no time)	Seconds vs milliseconds
Common in	REST JSON, documents, emails	Databases, logs, caches, metrics

Seconds vs milliseconds (the #1 bug)

JavaScript Date.now() returns milliseconds. Many databases, Redis TTLs, and POSIX APIs use seconds. Treating one as the other shifts the date by roughly 30,000 years or collapses it into 1970.

Rule of thumb for current dates:

• ~10 digits → seconds
• ~13 digits → milliseconds

Always document the unit in API fields: createdAtUnixSec or expiresAtMs beats a vague timestamp.

Both Tools.Town converters auto-detect common ranges; still verify when values are historical or far-future.

When ISO 8601 wins

Use ISO 8601 when:

• Public APIs return dates people or support staff may read in logs
• You need an explicit offset in the payload
• Interchange with spreadsheets, email, or non-developer tools matters
• You want a single string that encodes date, time, and zone intent

Prefer UTC (Z) in stored API values when the true meaning is an instant, then format for local display in the UI.

When Unix timestamps win

Use Unix integers when:

• You sort, difference, or expire records cheaply
• Storage and index size matter at scale
• Logs and metrics already speak epoch
• Clients are expected to format locally

Never assume the unit. Never mix second and millisecond columns without conversion.

Partial dates and “local midnight” traps

2026-08-16 in ISO is a calendar date, not a full instant. Interpreting it as midnight UTC versus midnight in Mumbai produces different Unix values.

If the business meaning is “the calendar day in India,” store the date (or a date + timezone policy), not a silent UTC midnight conversion. If the meaning is “this exact moment,” store a full instant (ISO with offset/Z, or Unix seconds/ms).

Timezones still matter for display

Unix time does not remove timezone bugs from UIs. Converting 1786874400 to a string in IST versus PST changes the wall clock even though the instant is identical.

Use the Timezone Converter when comparing wall times across regions. Keep storage in UTC or Unix; convert at the edge for display.

Year 2038 (awareness, not panic)

32-bit signed second counters overflow on 19 January 2038. Modern systems should use 64-bit storage. If you maintain legacy firmware or old databases, check the column type before relying on far-future expiry times.

Practical checklist for APIs

1. Decide: instant vs calendar date.
2. Pick ISO for public readability, Unix for compact machine use — or offer both.
3. Name the unit if using integers (sec / ms).
4. Prefer UTC for stored instants.
5. Document examples in both formats.
6. Reject ambiguous inputs in strict parsers rather than guessing.

Convert on Tools.Town

• Epoch Converter — Unix ↔ human date, seconds and milliseconds, relative time.
• Unix Timestamp Converter — bidirectional convert with ISO / UTC / local outputs and UTC offset.
• Time Format Converter — related time-of-day format help.
• Timezone Converter — wall-clock comparison across zones.

For elapsed clock intervals rather than format choice, see Elapsed Time vs Clock Duration vs Date Difference.