A Unix timestamp is a single number representing a point in time: the count of seconds that have elapsed since 00:00:00 UTC on January 1, 1970 — a moment known as the Unix epoch. Everything after that instant is a positive number; everything before it is negative. That's the entire definition — no timezone, no calendar, no daylight saving — which is exactly what makes it useful and exactly what causes the confusion covered below.
Seconds vs. milliseconds — the most common mix-up
The Unix timestamp standard is defined in seconds. But JavaScript's Date.now() and new Date().getTime() both return milliseconds since the epoch, and plenty of APIs and databases follow JavaScript's convention rather than the original Unix one. Mixing the two up is an easy, common bug: treat a millisecond value as seconds and a date lands roughly 1,970 years in the wrong direction; treat a second value as milliseconds and a "recent" timestamp resolves to some point in 1970.
A quick way to tell which one you have: a current second-based timestamp is 10 digits (as of 2026, roughly 1.7–1.8 billion); a current millisecond-based timestamp is 13 digits, about 1,000× larger. If a number you're looking at has 13 digits, it's almost certainly milliseconds.
Timezones: a timestamp itself has none
A Unix timestamp always refers to a specific, unambiguous instant — it has no timezone attached, because it doesn't need one; "seconds since the epoch" is the same number everywhere on Earth at the same moment. The timezone only enters the picture when you convert a timestamp to a human-readable date: "what time was it in Tokyo when timestamp X occurred" and "what time was it in New York" are different questions with different answers, even though X itself never changes. Bugs here almost always come from converting to a local date too early and then doing further math (like comparing two dates) on the already-localized values instead of the underlying timestamps.
The Year 2038 problem
Many older systems store a Unix timestamp as a signed 32-bit integer. A signed 32-bit integer can represent values only up to 2,147,483,647 — and the timestamp for 03:14:07 UTC on January 19, 2038 is exactly that number. One second later, the value overflows and wraps around to a large negative number, which — depending on how a given system handles it — gets interpreted as a date in 1901. This is the "Year 2038 problem," a direct sequel to Y2K, and it's why modern systems increasingly store timestamps as 64-bit integers, which won't overflow for roughly 292 billion years.
Try it yourself
Paste a timestamp into our Timestamp Converter — it auto-detects whether a value is in seconds or milliseconds by magnitude, and converts to local time, UTC, ISO 8601, and a relative ("3 hours ago") format. It also works in the other direction, from a picked date back to an epoch timestamp. Runs entirely in your browser.