What Is a Unix Timestamp?

A Unix timestamp — also called epoch time — is how computers actually store a moment in time. If you have ever seen a number like 1700000000 in a log file, a database column or an API response, that is it. It is a beautifully simple idea that solves a genuinely hard problem, and it has a small number of traps that catch almost every developer at least once.

The definition

A Unix timestamp is the number of seconds that have elapsed since 00:00:00 UTC on 1 January 1970 — a moment called the epoch.

So 1700000000 is 1.7 billion seconds after that instant, which lands on 14 November 2023. Times before 1970 are simply negative numbers.

Why 1970? It is arbitrary. The engineers building early Unix needed a starting point, picked a recent round date, and it stuck. There is no deeper significance to it.

Why it is such a good idea

Storing dates as text is a nightmare, and the timestamp avoids all of it:

• It is unambiguous. Is 03/04/2026 the 3rd of April or the 4th of March? It depends which country you are in. 1775520000 means exactly one instant, everywhere.
• Comparison and arithmetic are trivial. A bigger number is a later time. The gap between two moments is a subtraction. No calendar logic, no month lengths, no leap-year rules.
• It is compact. A whole date and time in a single integer.
• It sorts correctly with no special handling.

You will find epoch time in databases, HTTP headers, cookies, file metadata, and the exp and iat claims inside every JSON Web Token.

Trap 1: seconds vs. milliseconds

This is the most common bug in the entire topic, and everyone hits it.

Most languages — and the Unix definition itself — count epoch time in seconds. But JavaScript's Date.now() returns milliseconds. So does Java. Mix the two and your date is wrong by a factor of 1,000.

The symptom is unmistakable once you know it:

• Your date shows as 1970. You fed a seconds value into something expecting milliseconds. 1.7 billion milliseconds is only about 20 days after the epoch.
• Your date is in the year 55,000. You fed milliseconds into something expecting seconds.

The quick check is the digit count. A current timestamp in seconds is 10 digits. In milliseconds it is 13 digits. Count them — it takes a second and it tells you immediately which you have.

Trap 2: a timestamp has no timezone

This confuses people constantly, and getting it straight prevents a whole class of bugs.

A Unix timestamp is always UTC. It does not carry a timezone, because it does not need one — it identifies an instant, and an instant is the same instant everywhere in the world.

When it is 3pm in London it is simultaneously 10am in New York. Those are the same moment, and the same timestamp. The timezone only matters when you display the time to a human.

This gives you the correct architecture for handling time, and it is worth stating as a rule:

Store timestamps in UTC. Convert to a local timezone only at the moment of display.

Storing local times in a database is how you end up with data that is wrong twice a year, when daylight saving shifts and an hour is either repeated or skipped entirely.

Trap 3: leap seconds

A subtlety with a strange resolution. The Earth's rotation is not perfectly regular, so occasionally a leap second is inserted into UTC to keep clocks aligned with the planet.

Unix time ignores them. It pretends every day has exactly 86,400 seconds. This means Unix time is not, strictly, the true count of elapsed seconds since 1970 — it is off by the number of leap seconds that have occurred.

This is a deliberate trade. Handling leap seconds properly would make every date calculation depend on an unpredictable table of past adjustments. Pretending they do not exist keeps the arithmetic simple, at the cost of a handful of seconds of accuracy that virtually no application cares about.

The year 2038 problem

Older systems store the timestamp in a signed 32-bit integer, which can hold a maximum of 2,147,483,647.

That many seconds after the epoch falls on 19 January 2038. One second later, the integer overflows and wraps around to a large negative number — which is interpreted as December 1901. Systems that do date arithmetic will behave as though time has run backwards by 136 years.

This is a genuine, dated version of the Y2K problem, and it is a real concern for embedded systems, old databases and industrial equipment that may still be running in 2038.

The fix is straightforward and already widespread: use a 64-bit integer. That pushes the limit roughly 292 billion years into the future, which is comfortably longer than the universe has existed. For any new code, this is a non-issue.

Common mistakes to avoid

• Mixing seconds and milliseconds. Count the digits: 10 or 13.
• Storing local time instead of UTC. Store UTC; convert on display.
• Storing a timestamp as a string. Use an integer or a proper timestamp column.
• Using 32-bit storage for anything expected to outlive 2038.
• Assuming a day is always 86,400 seconds in local time. On daylight-saving days it is not — which is exactly why you should do date arithmetic in UTC.

Frequently asked questions

Why does my date show as 1 January 1970? The timestamp was zero, null, or a milliseconds value read as seconds.

Can a Unix timestamp be negative? Yes — it represents a time before 1970.

Is epoch time the same everywhere in the world? Yes. That is the entire point: it is a single, universal number for a single instant.

What is the current timestamp? Roughly 1.7–1.8 billion, and rising by one every second. Any 10-digit number starting with 17 is a date in the mid-2020s.

Convert a timestamp now

Use our Epoch Converter to turn any Unix timestamp into a readable date — it auto-detects seconds versus milliseconds — and to get the timestamp for any date. To see the same instant across cities, use the Time Zone Converter. Working with tokens? The exp claim inside a JWT is epoch time.