Unix Timestamps Explained (and How to Convert Them)

A Unix timestamp is one of the most common ways computers store a moment in time. If you’ve ever seen a field like 1755500000 in an API response or a log file and wondered what date it means, this guide is for you.

What a Unix timestamp actually is

A Unix timestamp (also called epoch time or POSIX time) is simply the number of seconds that have elapsed since a fixed reference point: 00:00:00 UTC on January 1, 1970, known as “the epoch.” So 0 is that exact instant, 60 is one minute later, and 1755500000 is roughly 55 years later.

Storing time as a single number is convenient: it’s compact, it’s easy to compare (bigger number = later), and it sidesteps the mess of time zones and date formats. The catch is that it’s meaningless to humans without conversion. Paste one into the Unix Timestamp Converter to see the readable date instantly.

The seconds-vs-milliseconds trap

This trips up almost everyone. There are two common conventions:

• Seconds — the traditional Unix format. A current timestamp is 10 digits (e.g. 1755500000).
• Milliseconds — what JavaScript’s Date.now() and many modern APIs use. A current timestamp is 13 digits (e.g. 1755500000000).

If your date comes out as some absurd year far in the future, you almost certainly passed milliseconds to something expecting seconds (or vice versa). The quick sanity check: a current timestamp in seconds is 10 digits. If yours is 13, it’s milliseconds — divide by 1000.

Time zones: timestamps are always UTC

A Unix timestamp has no time zone — it always refers to an instant in UTC. The confusion happens at display time: the same timestamp shows as different clock times depending on the viewer’s time zone. 1755500000 might be 3:00 PM in London and 10:00 AM in New York — but it’s the same instant. That’s actually the great strength of timestamps: store one number, display it correctly for every user. A good converter shows you both the UTC time and your local time so you can cross-check.

Why the epoch is 1970 — and the year 2038 problem

1970 was chosen simply because it was a convenient round date near when Unix was being developed. More interesting is the Year 2038 problem: older systems stored timestamps in a signed 32-bit integer, which can only count up to 2,147,483,647 seconds — a number it reaches on January 19, 2038. After that, those counters overflow and wrap around to a negative number, misreading the date as 1901. It’s the modern echo of the Y2K bug. The fix is straightforward — 64-bit timestamps, which won’t overflow for billions of years — and most current systems already use them.

Working with timestamps

• Get the current timestamp in seconds: it’s the count right now. Most converters have a “now” button.
• Compare two events: just subtract. The difference is the number of seconds (or milliseconds) between them.
• Convert to a date: feed the number to a converter and read it in UTC or local time.

Timestamps show up all over developer work — in JWT expiry claims (exp, iat), in log files, and in database records. Once you internalize “seconds since 1970, always UTC,” they stop being mysterious.