Skip to content
mathbehind

Unix Timestamps Explained, and Why 2038 Matters

A Unix timestamp is a count of seconds since 1 January 1970 UTC. Here is how to read one, the seconds vs milliseconds trap, and what happens in January 2038.

By Muhammad Ahmad. Published . 2 min read.

Want to run your own numbers?Unix Timestamp ConverterOpen the calculator

Open almost any database, log file or API response and you will find numbers like 1735689600 where you expected a date. That is a Unix timestamp: the number of seconds since midnight UTC on 1 January 1970, a moment known as the Unix epoch.

Storing time this way has real advantages. It is a single number, it sorts correctly, it is easy to subtract, and it means the same instant everywhere in the world, regardless of time zones.

Reading a timestamp

  • 0 is Thursday, 1 January 1970, 00:00:00 UTC.
  • 1735689600 is Wednesday, 1 January 2025, 00:00:00 UTC.
  • Negative numbers are moments before 1970, although some older systems do not support them.

A timestamp is always in UTC. Converting it to local time is a separate step, done when you display it, and that is where time zones and daylight saving come in.

Seconds or milliseconds?

Unix time is defined in seconds, but JavaScript's Date.now() and many web APIs use milliseconds. That gives you a quick check: a current timestamp in seconds has 10 digits, and one in milliseconds has 13.

Mixing them up is one of the most common date bugs. Treat a millisecond value as seconds and you get a date tens of thousands of years in the future. Treat seconds as milliseconds and you land in January 1970.

The year 2038 problem

Many older systems stored timestamps as signed 32-bit integers. The largest number a signed 32-bit integer can hold is 2,147,483,647.

The last second a 32-bit timestamp can hold

  1. Largest signed 32-bit value

    2³¹ − 1equals2,147,483,647

  2. As a date

    2,147,483,647 s after the epochequals19 Jan 2038, 03:14:07 UTC

One second later, a 32-bit counter overflows and wraps around to a large negative number, which systems read as a date in December 1901. It is the same kind of problem as Y2K, but for software that stores time as a 32-bit number.

Are you affected?

Most modern operating systems, languages and databases now use 64-bit timestamps, which will not run out for billions of years. The risk sits in older code and hardware: embedded devices, legacy databases, file formats with fixed 32-bit time fields, and any code that squeezes a timestamp into a 32-bit integer.

Tip: Storing dates after January 2038, like a long contract end date or a mortgage schedule? Test that your stack handles them now, not in 2038.

Keep reading