Chrono Time guide

Unix timestamps: what they are and why UTC matters

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.

FormatExampleWhat to watch for
Seconds1716124800Common in Unix tools, many back-end systems and APIs.
Milliseconds1716124800000Common in JavaScript and browser timestamps.
ISO 86012026-05-19T14:00:00ZHuman-readable, explicit UTC marker, often easier to debug.

Seconds versus milliseconds

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.

Why timestamps always start from UTC

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.

Practical examples

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.

FAQ

Can Unix timestamps store a timezone?

No. They store a point in time. The timezone comes later when you format that instant for display.

Should an API return timestamps or strings?

Either can work, but the contract must be explicit. ISO 8601 UTC strings are often easiest to debug; raw timestamps are compact and fast.

Why do browsers use milliseconds?

JavaScript Date APIs traditionally work with millisecond precision, so front-end code often uses 13-digit values.

Related pages

Chrono Time uses optional analytics and advertising cookies only after consent where required. Essential storage for site preferences stays enabled. See the privacy policy.