What Is Unix Time? The Epoch Explained

Every time you check a timestamp in a database, parse a date from an API, or debug a time-related issue in code, you’re likely dealing with Unix time. It’s one of the most fundamental concepts in computing, yet many people use it daily without understanding what it actually is.

The Basic Concept

Unix time (also called Unix timestamp, Epoch time, or POSIX time) is a system for tracking time as a single number: the count of seconds that have elapsed since January 1, 1970, at 00:00:00 UTC. That specific moment — midnight on New Year’s Day 1970 in the UTC time zone — is called the Unix epoch.

Right now, the Unix timestamp is approximately 1.77 billion (and counting). That number represents every second that has passed since the epoch.

The beauty of this system is its simplicity. Instead of dealing with years, months, days, hours, minutes, seconds, time zones, and calendars, you have one number. Want to know the difference between two moments in time? Subtract one timestamp from the other. Want to add three hours? Add 10,800 (3 × 60 × 60). No calendar math, no month-length lookups, no DST complications.

Why 1970?

The Unix epoch wasn’t chosen for any astronomical or historical reason. When Ken Thompson and Dennis Ritchie developed Unix at Bell Labs in the late 1960s, they needed a reference point for their time system. They originally used January 1, 1971, then moved it to 1970 as a rounder number. The 32-bit integer they used could represent about 136 years, and starting from 1970 meant the system would work until 2106 (for unsigned integers) or 2038 (for signed integers).

The choice was pragmatic, not symbolic. It just needed to be a point in the relatively recent past.

How Computers Use It

When your computer stores a file’s modification date, records when a database entry was created, or timestamps a log message, it typically stores a Unix timestamp. The human-readable date you see (“February 5, 2026, 10:30 AM”) is generated on-the-fly by converting the timestamp using your local time zone settings.

This conversion process is why the same timestamp displays as different clock times in different time zones — the underlying number is the same, but the local representation changes.

Programming languages provide built-in functions for this conversion:

• JavaScript: Date.now() returns the current time in milliseconds since the epoch
• Python: time.time() returns the current time in seconds (with decimal fractions)
• SQL: Functions like UNIX_TIMESTAMP() and FROM_UNIXTIME() convert between formats

Many modern systems use millisecond timestamps (the epoch count in milliseconds rather than seconds), which provides sub-second precision. JavaScript’s Date.now() returns this format, producing 13-digit numbers like 1,770,000,000,000.

Negative Timestamps and the Pre-Epoch World

Timestamps before the epoch are represented as negative numbers. January 1, 1969, at midnight UTC is timestamp -31,536,000 (negative 365 days worth of seconds). This means Unix time can represent dates before 1970, though not all systems handle negative timestamps correctly.

The Year 2038 Problem

The most famous issue with Unix time is the Year 2038 Problem (Y2K38). Many systems, especially older ones, store Unix timestamps as a signed 32-bit integer. The maximum value of a signed 32-bit integer is 2,147,483,647, which corresponds to:

January 19, 2038, at 03:14:07 UTC

One second later, the counter overflows. On systems that haven’t been updated, the timestamp would wrap around to the minimum value of a signed 32-bit integer, which represents a date in December 1901. This could cause software to behave as if time has jumped backwards by 137 years.

The fix is straightforward: use 64-bit integers. A signed 64-bit timestamp won’t overflow until approximately 292 billion years from now — well after the sun has burned out. Most modern operating systems, databases, and programming languages have already made this transition. Linux completed its 64-bit time transition for 32-bit systems in kernel version 5.6 (2020).

However, embedded systems, legacy software, and devices with long lifespans (industrial controllers, automotive systems, medical devices) may still use 32-bit timestamps. These systems will need updates before 2038.

Leap Seconds

One complication that Unix time deliberately ignores is leap seconds. The Earth’s rotation is slightly irregular, so approximately every year to three years, a leap second is added to UTC to keep atomic time aligned with astronomical time. There have been 27 leap seconds added since 1972.

Unix time pretends leap seconds don’t exist. Each day is exactly 86,400 seconds, and the Unix timestamp count simply skips over or smears the leap second. This means Unix time isn’t technically a precise count of elapsed SI seconds — it’s a count of “UTC seconds,” where some seconds are repeated or skipped.

In practice, this rarely causes problems. The international community has even agreed to abolish leap seconds by 2035, after which UTC will be allowed to gradually drift from astronomical time.

Unix Time in Daily Life

You encounter Unix timestamps more often than you might think:

• File systems store creation and modification dates as timestamps
• Web cookies use timestamps for expiration dates
• Social media posts are ordered by timestamp
• Financial systems record transactions with millisecond timestamps
• Log files across every server and application use timestamps for sequencing

The Unix epoch is one of computing’s most successful conventions. Its simplicity — one number, counting seconds from a fixed point — has made it the universal language for representing time in software. Every phone, server, website, and smart device in the world is, at this very moment, counting seconds from midnight on January 1, 1970.