TechCompare LogoTechCompare

ISO 8601 vs Unix timestamps: which date format should your API use?

Use ISO 8601 strings for public APIs and anywhere a human might read the raw data. Use Unix timestamps for internal services, high-volume event streams, and anywhere you need to do date math. You can have both: store as Unix timestamp in the database, serialize as ISO 8601 at the API boundary.

ISO 8601 dates (like 2026-06-03T14:30:00Z) are human-readable, self-describing, and sortable as strings. Unix timestamps (like 1780511400) are compact integers that are timezone-independent and trivial to do math on. Choosing between them for your API or database is a trade-off between developer experience and machine efficiency.

By TechCompare · Updated

Unix timestamp
1,780,511,400
Seconds since epoch
ISO 8601
2026-06-03T14:30:00.000Z
Wed, 03 Jun 2026 18:30:00 GMT
Category
Format Comparison
Timestamp knowledge base

How this is calculated

ISO 8601 wins on developer experience. Anyone reading a log file or API response can instantly understand the date without a converter. It's the standard for JSON APIs (JSON doesn't have a native date type), and it's what JavaScript's Date.toISOString() produces. Unix timestamps win on compactness (10 digits vs 24 characters) and math (subtracting two timestamps gives you a duration in seconds with no parsing). Databases handle both well. PostgreSQL has native timestamp types. SQLite stores everything as strings anyway.

Verdict

The trade is concrete in both directions. ISO 8601 is 20+ characters per timestamp ("2026-06-03T14:30:00.000Z") versus Unix's 10 digits (1780511400), it's what JSON APIs use because JSON has no native date type, and anyone reading a log or API response can parse it at a glance without a converter. Unix timestamps are the format for date math: subtracting two integers gives a duration in seconds with no parsing step, and the byte savings add up at high-volume event-stream scale. The hybrid pattern most production stacks converge on is store-as-Unix in the database for compactness and math, serialize-as-ISO at the API boundary for human readability, with some APIs returning both `created_at` (ISO) and `created_at_ts` (Unix) when clients need both modes. The one hard rule for ISO: always include the offset or 'Z', never emit a timezone-less ISO string because that's ambiguous.

More Timestamp scenarios

Frequently asked questions

Is ISO 8601 always in UTC?
No. ISO 8601 can include timezone offsets like +05:30 or -08:00. The 'Z' suffix explicitly means UTC. Without a timezone indicator, the time is assumed to be local, which is ambiguous and should be avoided in APIs.
Which format is smaller, ISO 8601 or Unix timestamp?
Unix is smaller. A Unix timestamp is typically 10 digits as a number (e.g. 1780511400), while the same instant in ISO 8601 is 20+ characters (`"2026-06-03T14:30:00.000Z"`). For high-volume event streams and log storage, the byte savings add up. For human-readable contexts, ISO is worth the size.
Should my API return ISO 8601, Unix timestamp, or both?
Most modern REST APIs return ISO 8601 in JSON responses and accept ISO 8601 in requests. The spec is human-readable and unambiguous. For internal microservice-to-microservice APIs where neither side renders the data, Unix timestamps save bytes and math. Some hybrid APIs return both: `created_at` as ISO and `created_at_ts` as Unix for client-side math.