What is a Unix timestamp?
A Unix timestamp — also called epoch time or POSIX time — is a single number that identifies one exact instant: the count of seconds that have elapsed since 1970-01-01 00:00:00 UTC, an instant known as the Unix epoch. Instead of storing "14 November 2023, 22:13, in some time zone, in some language's format", a system stores 1700000000, and every computer on Earth agrees on what that means. Sorting is trivial (bigger number, later time), arithmetic is trivial (subtract two timestamps to get a duration), and time zones cannot corrupt the value, because the value has no time zone at all.
That elegance is why timestamps are everywhere: database columns, API
responses, log lines, JWT claims (iat, exp),
file metadata and message queues all carry them. And it is why a fast,
trustworthy converter matters — the number is meaningless to a human
until it is turned back into a date, in the right unit and the right
time zone.
How to use this converter
- Timestamp to date: paste any numeric timestamp into the first field. The tool detects whether it is in seconds, milliseconds or microseconds from its size, converts it, and shows UTC, your local time, ISO 8601 and a relative description ("3 days ago") side by side.
- Date to timestamp: pick a date and time in the second field and press Convert date. You get the timestamp in both seconds and milliseconds, ready to paste into code or a database query.
- The banner at the top shows the current timestamp ticking once per second — handy when you just need "now" as a number.
Seconds, milliseconds, microseconds: the eternal mix-up
Unix defines the timestamp in seconds. JavaScript, however, measures
time in milliseconds (Date.now() returns milliseconds),
and Java, Go and various APIs use a mixture of milliseconds, microseconds
and even nanoseconds. The units differ by factors of a thousand, and the
failure mode is silent: a millisecond value interpreted as seconds is a
date in the year 51380 (or an overflow error, if you are lucky), while a
seconds value interpreted as milliseconds is a date a few hours after
the epoch — January 1970. If a converted date looks absurd, the unit is
almost certainly wrong; count the digits. Ten digits is seconds,
thirteen is milliseconds, sixteen is microseconds, at least until the
year 2286 moves seconds into eleven digits.
Leap seconds are the other quiet simplification: Unix time pretends every day has exactly 86,400 seconds and simply repeats or smears the leap second when one is inserted. For nearly all software purposes this does not matter, but it is why Unix time is not a perfectly faithful count of physical seconds since 1970.
Examples
| Timestamp | Unit | UTC date |
|---|---|---|
| 0 | seconds | Thu, 01 Jan 1970 00:00:00 GMT |
| 1000000000 | seconds | Sun, 09 Sep 2001 01:46:40 GMT |
| 1700000000 | seconds | Tue, 14 Nov 2023 22:13:20 GMT |
| 1700000000123 | milliseconds | Tue, 14 Nov 2023 22:13:20.123 GMT |
| -1 | seconds | Wed, 31 Dec 1969 23:59:59 GMT |
Tips
- Store seconds, display local. Keep timestamps in UTC-based seconds (or milliseconds) in storage, and convert to the reader's time zone only at display time — as this page does.
- Check the claim times in tokens. A JWT's
expis in seconds; pasting it above instantly shows when a session really expires. - Beware 32-bit storage. Any system storing timestamps in a signed 32-bit integer breaks in January 2038.
For the full story — epoch trivia, leap seconds, the 2038 problem and time-zone handling — read our guide Unix timestamps explained, and for the UTC/GMT confusion see the timestamps guide's time-zone section.