Convert epoch timestamps to dates and dates to timestamps.
A Unix timestamp is the number of seconds elapsed since 00:00:00 UTC on 1 January 1970, known as the epoch. It is the standard way computers store a moment in time, because it is a single integer that needs no time zone, no calendar rules and no locale.
Timestamps before the epoch are negative, which is how dates in 1969 and earlier are represented.
This is the most frequent source of confusion. Unix timestamps are conventionally in seconds, but JavaScript's Date.now() and several other environments return milliseconds — a thousand times larger.
| Digits | Unit | Example |
|---|---|---|
| 10 | Seconds | 1767225600 |
| 13 | Milliseconds | 1767225600000 |
| 16 | Microseconds | 1767225600000000 |
A quick check: a 10-digit timestamp is seconds and lands in the present era. If a date comes out as 1970, you have passed seconds where milliseconds were expected. If it comes out tens of thousands of years in the future, the reverse. Dividing or multiplying by 1,000 fixes it.
A timestamp is always UTC. It represents an absolute instant, not a local wall-clock time. The same timestamp is 12:00 in London, 13:00 in Paris and 17:30 in Delhi — the same moment described differently.
This is precisely why timestamps are the right way to store times in a database. Storing local times means storing an ambiguous value that depends on a time zone you may not have recorded, and that changes meaning when daylight saving rules are revised. Store UTC, convert for display.
Daylight saving makes this concrete: when clocks go back, one local hour occurs twice, so a local timestamp in that window is genuinely ambiguous. When clocks go forward, an hour does not exist at all. Timestamps have neither problem.
Timestamps were traditionally stored in a signed 32-bit integer, which overflows on 19 January 2038 at 03:14:07 UTC. At that instant the value wraps to negative, and unpatched systems will read the date as December 1901.
Most modern systems use 64-bit timestamps, which push the limit roughly 292 billion years out. The remaining risk sits in embedded systems, older databases, file formats with fixed 32-bit fields and legacy code — anywhere the storage width is fixed and cannot easily be widened. It is the same class of problem as Y2K, and like Y2K it will largely be a non-event because of work done in advance.
Unix time deliberately pretends every day is exactly 86,400 seconds. Real UTC has had 27 leap seconds inserted since 1972 to track the Earth's slowing rotation, and Unix time simply does not count them — a leap second either repeats a timestamp value or is smeared across a longer period, depending on the system.
This means Unix time is not a true count of elapsed SI seconds since 1970; it is off by the number of leap seconds since. The trade was deliberate: consistent, simple date arithmetic was judged more valuable than exact physical elapsed time, and for almost every application it is.
iat and exp claims in JSON Web Tokens.Conversion runs locally in JavaScript using your device's clock and time zone for the local display. Nothing is transmitted, which matters given that timestamps often appear in log excerpts and tokens that are not meant to leave your machine.
You almost certainly passed a value in seconds where milliseconds were expected, or a very small number. A 10-digit timestamp is seconds and a 13-digit one is milliseconds — multiply or divide by 1,000 as needed.
UTC, always. A timestamp is an absolute instant with no time zone attached. Converting it for display applies your local offset, which is why the same value shows different clock times in different places.
Signed 32-bit timestamps overflow on 19 January 2038, wrapping to negative and reading as 1901. Modern 64-bit systems are unaffected; the risk sits in embedded devices, legacy code and fixed-width file formats.
Yes. Negative values represent times before 1 January 1970 — so -86400 is 31 December 1969. Some older software handles negative timestamps poorly, which is worth knowing when working with historical dates.
No. Unix time treats every day as exactly 86,400 seconds and ignores the 27 leap seconds added since 1972. This keeps date arithmetic simple at the cost of not being a true count of elapsed physical seconds.