Can Unix timestamps store a timezone?
No. They store a point in time. The timezone comes later when you format that instant for display.
Chrono Time guide
A Unix timestamp represents one exact instant as the number of elapsed seconds or milliseconds since 00:00:00 UTC on 1 January 1970. That makes timestamps ideal for APIs, audit logs, message queues and databases.
| Format | Example | What to watch for |
|---|---|---|
| Seconds | 1716124800 | Common in Unix tools, many back-end systems and APIs. |
| Milliseconds | 1716124800000 | Common in JavaScript and browser timestamps. |
| ISO 8601 | 2026-05-19T14:00:00Z | Human-readable, explicit UTC marker, often easier to debug. |
The most common conversion bug is treating milliseconds as seconds or the other way around. If your app shows a date thousands of years in the future, you probably passed a 13-digit JavaScript timestamp into code that expected seconds.
A timestamp is not tied to London, New York or Tokyo. It records a universal instant, and then the display layer formats that instant for a local audience. That is why UTC is foundational here: one stored value, many local representations.
Webhook signatures, token expiry times, job schedulers and server logs all benefit from timestamp storage because ordering events is straightforward. When you need a readable display, convert the instant into the user's local zone with a clear label.
No. They store a point in time. The timezone comes later when you format that instant for display.
Either can work, but the contract must be explicit. ISO 8601 UTC strings are often easiest to debug; raw timestamps are compact and fast.
JavaScript Date APIs traditionally work with millisecond precision, so front-end code often uses 13-digit values.