Unix Timestamp Converter

What is a Unix Timestamp?

A Unix timestamp is the number of seconds that have elapsed since January 1, 1970 at 00:00:00 UTC — a reference point known as the Unix Epoch. Because it is timezone-independent, Unix timestamps are ideal for storing and comparing times across different systems and regions. A timestamp of 0 represents exactly the epoch start, and negative values represent times before 1970.

Seconds vs Milliseconds

Traditional Unix timestamps count elapsed seconds and are typically 10 digits long (e.g. 1700000000). JavaScript's Date.now() and many modern APIs return milliseconds instead, producing 13-digit values (e.g. 1700000000000). To convert seconds to milliseconds, multiply by 1000. To convert milliseconds to seconds, divide by 1000 and floor the result.

Unix Timestamp vs ISO 8601

Unix timestamps are compact integers, making them efficient for storage, sorting, and arithmetic. ISO 8601 (e.g. 2024-03-15T09:30:00.000Z) is a human-readable string format that's self-describing and unambiguous. Use timestamps internally in databases and APIs; use ISO 8601 in logs, user interfaces, and anywhere a human might read the value.

How to Tell Seconds from Milliseconds at a Glance

Digit count is a reliable heuristic for any timestamp in the modern era, and this tool applies it automatically.

Getting the unit wrong produces errors that are absurd rather than subtle, which is the one mercy here. Read a millisecond value as seconds and you land in the year 55,844. Read seconds as milliseconds and everything collapses into January 1970 — the classic "all my records show 1970" bug, and a reliable sign that a value was divided by 1000 one time too many.

Timestamps in Common Languages

The unit each language returns by default is the usual source of confusion at a service boundary.

When a JavaScript front end sends Date.now() to a Python backend that assumes time.time(), every date lands roughly 50,000 years in the future. Normalising on one unit — seconds is the more common convention for APIs — at the boundary avoids the whole category. If the API in question returns those timestamps inside a JSON body, our YAML and JSON converter is handy for reformatting the payload while you inspect it.

Timestamp Pitfalls Worth Knowing

Choosing How to Store Time

Three sensible options, each with a different trade-off:

• 64-bit integer epoch. Compact, sorts and compares trivially, arithmetic is simple, and it is unambiguous. The cost is that it is unreadable to a human eye scanning raw rows.
• ISO 8601 string. Self-describing and readable, sorts correctly as a string when zero-padded and stored in UTC, but uses more space and requires parsing before arithmetic.
• Native timestamp column (TIMESTAMPTZ in PostgreSQL). Usually the best choice: the database handles conversion, and date functions operate directly on the value. Prefer the timezone-aware variant — plain TIMESTAMP discards the offset and reintroduces the ambiguity you were trying to avoid.

Whichever you pick, the durable rule is to store instants in UTC and apply the user's timezone only at the point of display. Storing local time is the root cause of the annual crop of daylight-saving bugs, where an hour either repeats or never happens. If you are writing the queries that read those columns, our SQL formatter makes the date arithmetic easier to read.

Frequently Asked Questions