A Unix timestamp is a single number that represents an exact moment in time: the number of seconds that have passed since midnight UTC on January 1, 1970 — a moment programmers call "the epoch." It shows up constantly in logs, APIs, databases, and file metadata because a single integer is simpler to store, compare, and sort than a formatted date string.
What a Unix Timestamp Is
The number itself only counts upward, one per second, from the epoch. As of mid-2026, that count is somewhere past 1.78 billion — meaning about 1.78 billion seconds have elapsed since January 1, 1970. It's not tied to any particular timezone or calendar format; it's just a raw count of elapsed seconds, which is exactly why it's useful for computers even though it's meaningless to a human without conversion.
Seconds vs. Milliseconds
The original Unix standard counts in seconds, but JavaScript's built-in Date.now() returns milliseconds — exactly 1000 times larger. This is the single most common source of confusion when timestamps move between systems: a value like 1735689600 is a valid seconds-based timestamp, while 1735689600000 is the same instant in milliseconds. Feeding a seconds-based timestamp into a function expecting milliseconds (or vice versa) produces a date that's wildly wrong — usually landing somewhere in 1970 or the year 56000-something.
The Year 2038 Problem
Older systems store a Unix timestamp as a signed 32-bit integer, which tops out at 2,147,483,647 — a value reached at 03:14:07 UTC on January 19, 2038. After that instant, the count overflows and wraps to a large negative number, which many affected systems then misinterpret as a date back in December 1901. This is the same category of bug as the Y2K problem, just with a different number and a later deadline. Most modern software has already migrated to 64-bit timestamps, which won't overflow for roughly 292 billion years, but plenty of older embedded systems and file formats still use the 32-bit version.
Timezones and Timestamps
A raw timestamp is timezone-independent — it represents one specific instant everywhere on Earth simultaneously. Timezone only enters the picture when you convert that instant into a human-readable date and clock time, since the same timestamp displays as different local times in New York, London, and Tokyo. If two systems disagree about what time a given timestamp represents, the timestamp itself is fine; the bug is almost always in how one of them is formatting it for display.
Converting a Timestamp
Rather than doing epoch math by hand, paste a timestamp — or a date — into our free Timestamp Converter. It auto-detects whether you've entered seconds or milliseconds, shows the result in relative time plus RFC 2822, ISO 8601, and UTC formats, and can batch-convert several timestamps at once.
FAQ
Why do timestamps in JavaScript look 1000x too large? The Unix standard defines a timestamp as seconds since the epoch, but JavaScript's Date.now() and new Date().getTime() return milliseconds instead. A timestamp of 1735689600 (seconds) becomes 1735689600000 in JavaScript — exactly 1000 times larger — which is the most common source of off-by-1000x bugs when mixing timestamps between JavaScript and other languages or APIs.
What is the Year 2038 problem? Older systems store Unix timestamps as a signed 32-bit integer, which can only count up to 2,147,483,647 seconds after the epoch — a limit reached on January 19, 2038. After that instant, those systems overflow and wrap around to a negative number, which typically gets interpreted as a date in 1901. Modern systems avoid this by using 64-bit integers, which won't overflow for billions of years.
Are Unix timestamps affected by timezones? No — a Unix timestamp represents a single, absolute instant in time (seconds since midnight UTC on January 1, 1970), the same moment everywhere on Earth. Timezone only comes into play when you convert that timestamp into a human-readable date and time, since the same instant displays as a different local clock time depending on which timezone you're rendering it in.
Can Unix timestamps represent dates before 1970? Yes, as negative numbers. A timestamp of -86400, for example, represents exactly one day before the epoch: December 31, 1969. Most modern parsers handle negative timestamps correctly, though some older or stricter systems reject them, so it's worth checking if you're working with historical dates.