Unix Timestamps Explained: The 1970 Epoch and the Year 2038 Problem

If you've ever looked at an API response, a server log, or a database field and seen a number like 1719446400 instead of a readable date, you've probably wondered what it actually represents — this is a Unix timestamp, one of the most common ways computers actually store time internally, even though it looks nothing like a date.

Quick summary: A Unix timestamp counts the number of seconds that have passed since January 1, 1970, at 00:00:00 UTC — a moment known as the Unix epoch. It's timezone-independent and easy for computers to compare and store, which is why it's the standard format for APIs, databases, and log files. It also has a well-known limitation: on systems that store it as a 32-bit number, it will overflow on January 19, 2038 — a real, well-documented issue called the Year 2038 problem.

What a Unix timestamp actually is

A Unix timestamp is just a single integer: the number of seconds since the epoch. No time zone, no calendar formatting, no ambiguity about month order — just a count. That simplicity is exactly why computers like it. Comparing two timestamps to see which happened first is just comparing two numbers, and storing a moment in time takes a single field instead of a formatted string.

Many Unix-style timestamps you'll encounter in server logs and databases are in seconds — a 10-digit number for dates in the current era. JavaScript and many modern APIs use milliseconds instead, for extra precision, which shows up as a 13-digit number. The two are easy to tell apart just by length, and to convert milliseconds to seconds, just divide by 1,000.

Why January 1, 1970?

There's no deep symbolic reason. When Unix's time-keeping system was being built in the early 1970s, its developers needed a fixed starting reference point, and January 1, 1970 was simply a clean, recent, round date at the time the system was designed. It wasn't chosen to commemorate anything — it just stuck as the standard, and "Unix time" using that reference point spread far beyond Unix itself, into essentially every modern computing system.

The Year 2038 problem

Here's where it gets genuinely interesting. Many older and embedded systems store a Unix timestamp as a 32-bit signed integer, which can only hold values up to 2,147,483,647. Adding that many seconds to the epoch lands on a very specific moment: January 19, 2038, at 03:14:07 UTC. One second later, a 32-bit timestamp overflows — the same way an odometer rolls over — and wraps around to a negative number, which many systems will misread as a date back in December 1901.

This is often compared to the Y2K bug, and the comparison is fair: it's the same basic category of problem, a fixed-width number silently running out of room. Most modern software has already moved to 64-bit timestamps, which won't overflow for roughly 292 billion years, so the remaining risk is concentrated in older embedded systems, legacy databases, and hardware that's harder to update — things like industrial control systems and other long-lived, hard-to-patch software.

Local time vs. UTC

A Unix timestamp itself has no time zone — it's the same number everywhere on Earth at any given instant, which is exactly why it's useful for computers talking to each other across time zones. What varies is how that number gets displayed: your local time is just UTC adjusted by your device's time zone offset. When converting a timestamp to a readable date, it's worth checking whether you're looking at UTC or your local time, since the same timestamp can look like two different clock times depending on which one you're reading.

A few reference points worth knowing

• Timestamp 0 is the epoch itself: January 1, 1970, 00:00:00 UTC
• Timestamp 1,000,000,000 landed on September 9, 2001 — a billion seconds after the epoch, informally marked by some as a small tech milestone at the time
• Timestamp 2,147,483,647 is the exact moment the Year 2038 problem hits: January 19, 2038, 03:14:07 UTC

Converting timestamps without doing the math

For most everyday cases, none of this needs to be calculated by hand. Our Unix Timestamp Converter converts a timestamp to a readable date, or a date to its timestamp, and automatically detects whether you've entered seconds or milliseconds.

If you're also dealing with dates written in different regional formats, the Date Format Converter shows any date in every common format at once, including its Unix timestamp.

Related calculators

• Unix Timestamp Converter — convert Unix timestamps to and from readable dates
• Date Format Converter — see any date in every common format instantly
• Time Zone Converter — convert a date and time between any two time zones
• Days Between Dates — count the exact days between any two dates

FAQ

What is a Unix timestamp? A Unix timestamp is the number of seconds that have elapsed since January 1, 1970, at 00:00:00 UTC. It's a compact, timezone-independent way for computers to store and compare moments in time.

Why does Unix time start on January 1, 1970? There's no special significance to the date — it was simply a convenient, recent reference point when Unix's time system was designed in the early 1970s, and it became the standard from there.

What is the Year 2038 problem? Systems that store Unix timestamps as 32-bit signed integers will run out of room on January 19, 2038, at 03:14:07 UTC. After that instant, the number overflows and can be misread as a date in 1901. Most modern systems have already moved to 64-bit timestamps to avoid this, but some older or embedded systems remain at risk.

What's the difference between a 10-digit and 13-digit timestamp? A 10-digit timestamp counts seconds since the epoch; a 13-digit timestamp counts milliseconds, for extra precision. Most server logs and databases use seconds, while JavaScript and many web APIs use milliseconds.

Is a Unix timestamp the same everywhere in the world? Yes — a Unix timestamp represents a single, specific instant in UTC, regardless of where you are. What changes based on location is only how that instant gets displayed as a local date and time.

Can I decode a timestamp from a JWT token? Yes. JWT tokens include iat (issued at) and exp (expiration) fields as Unix timestamps in seconds. Paste either value into a timestamp-to-date converter to see exactly when a token was issued or when it expires.