The Unix Timestamp Explained: What Second Zero Really Means

Updated on March 31, 2026

Right now, as you read this, there is a number ticking forward somewhere deep in your computer's kernel. It's probably somewhere in the neighborhood of 1,750,000,000 — give or take a few million depending on exactly when you landed on this page. That number is the Unix timestamp, and it's one of the most quietly consequential design decisions in the history of computing. It's the reason your phone knows what time it is, the reason your bank's transaction records line up correctly across three time zones, and the reason "Y2K38" is a thing software engineers actually worry about.

Let's start at second zero.

January 1, 1970, 00:00:00 UTC — The Arbitrary Choice That Stuck

The Unix timestamp counts the number of seconds that have elapsed since midnight on January 1, 1970, Coordinated Universal Time. This moment is called the Unix epoch, and the count that emerges from it is called epoch time, POSIX time, or just "the timestamp."

Why 1970? The honest answer is: because the people building Unix in the late 1960s needed to pick something, and 1970 was recent and round. Ken Thompson, Dennis Ritchie, and their colleagues at Bell Labs were designing the system around 1969–1971. They needed a reference point for the system clock. 1970 was early enough that dates in the system's recent past (like file modification times) would be expressible as small positive integers, but not so early that the epoch count itself became unwieldy.

An earlier proposed epoch was January 1, 1971 — meaning the very first Unix implementations may have used a slightly different anchor. The standard eventually settled on January 1, 1970. There was no deep astronomical reason, no alignment with a leap year or historical event. It was engineering pragmatism: pick a number, document it, move on. The choice didn't need to be optimal. It needed to be shared.

That shared-ness is everything. If your system and my system both count from the same second, we can compare notes without any conversion overhead. Time becomes a globally comparable integer.

Why Seconds? Why Not Milliseconds, or Days?

This is actually a more interesting question than it first appears. The resolution of the epoch — seconds — reflects a deliberate tradeoff made in an era of severe memory constraints.

In the early 1970s, storing a time value efficiently mattered. A 32-bit signed integer representing seconds gives you a range from roughly −2.1 billion to +2.1 billion seconds around the epoch. That covers dates from December 1901 to January 2038 — generous enough for any system that expected to be replaced within a decade. And at second-level resolution, you could timestamp file modifications, process start times, and network events without wasting space on sub-second precision that most hardware couldn't even measure reliably.

Modern systems have largely moved to 64-bit integers. A 64-bit signed epoch in seconds covers roughly ±292 billion years — a number so large it encompasses the expected lifespan of the universe multiple times over. In practice, modern APIs like clock_gettime() on Linux give you nanosecond precision via a struct with two fields: seconds since epoch (tv_sec) and nanoseconds offset (tv_nsec). You get both precision and backward compatibility.

JavaScript's Date.now() returns milliseconds since epoch, which is why you'll sometimes see timestamps like 1750000000000 in web contexts — just the Unix timestamp multiplied by 1,000. Easy to convert, easy to mistake for something else entirely if you're not paying attention.

What "UTC" Actually Means Here — And Why It Matters

The epoch is defined in UTC, not in any local timezone. This is crucial. The Unix timestamp doesn't know what city you're in. It's a count of SI seconds from a fixed point in absolute time. Your local timezone offset is a display concern, not a storage concern.

This means that two computers in Tokyo and New York, with their clocks properly synchronized via NTP, will report the same Unix timestamp at the same instant — even though one is 14 hours ahead of the other in local time. Timezone conversion is applied at the point of display, not at the point of storage. It's a clean separation of concerns that most time-handling bugs violate.

The practical implication: if you're building any system that stores timestamps — a database, a log file, an API response — store UTC epoch values or UTC-formatted strings. Convert to local time only when showing the value to a human. This single rule eliminates an enormous category of timezone-related bugs.

Leap Seconds: The Inconvenient Wrinkle

Here's where it gets uncomfortable. The Unix timestamp doesn't account for leap seconds.

The Earth's rotation is not perfectly uniform. Occasionally — about 27 times since 1972 — the International Earth Rotation and Reference Systems Service (IERS) has added a "leap second" to UTC to keep it aligned with astronomical time (UT1). These are inserted as 23:59:60 on certain dates.

POSIX time simply pretends leap seconds don't exist. It assumes every day is exactly 86,400 seconds long. When a leap second occurs, POSIX-compliant systems either repeat a second or smear the leap over a longer period. Google, Amazon, and others use "leap smearing" — spreading the extra second over a 24-hour window so timestamps never go backward or pause. This means their servers' clocks drift slightly from true UTC for a day, then re-converge.

For most applications, this doesn't matter. For high-frequency trading systems, GPS synchronization, or astronomical observatories, it can matter enormously. It's a known, accepted limitation of the epoch standard — traded off against the massive simplification of having a monotonically increasing integer represent time.

The Y2K38 Problem

Remember Y2K? Unix has its own version, and the deadline is January 19, 2038, at 03:14:07 UTC.

That's the moment when a signed 32-bit integer representing seconds since the epoch overflows. It rolls from 2,147,483,647 to −2,147,483,648, which represents December 13, 1901. Systems that haven't been updated to use 64-bit time_t values will experience this as a catastrophic time discontinuity.

Most modern desktop and server operating systems have already transitioned to 64-bit time values. The problem is with embedded systems — routers, industrial controllers, older IoT devices — that were built with 32-bit assumptions and may still be running in 2038. It's a slow-motion problem that the industry is mostly handling correctly, but quietly.

Linux's 32-bit kernel support for time_t was officially extended in 2020 with kernel 5.6, which added support for 64-bit time on 32-bit architectures. This was a genuinely significant engineering effort, touching thousands of lines of kernel code.

How Epoch Time Underpins the Infrastructure You Use Daily

When you log into a website and your session cookie has an expiration, that expiration is almost certainly stored as a Unix timestamp. When your database records an order, the created_at column is typically a Unix timestamp or a UTC datetime derived from one. When a distributed system tries to establish event ordering across multiple servers — using something like a vector clock or a Lamport timestamp — the Unix epoch provides the absolute time anchor.

HTTP itself bakes this in. The Last-Modified header, the Expires header, JWT token expiration (exp claim), OAuth token lifetimes, S3 presigned URL expiration — all of these use seconds since epoch as their native unit. It's pervasive precisely because it's simple: one integer, universally comparable, trivially serializable.

Even conversion tools — whether you're converting a timestamp to a human-readable date, or going the other direction from a date string into epoch seconds — are ultimately doing simple arithmetic: multiply by 86,400 for days, adjust for timezone offset, correct for leap years. There's no magic. The epoch is just an anchor; the math is just counting.

Converting Epoch Time in Practice

A few common conversions that come up constantly:

Current timestamp in most environments:

  • Python: import time; int(time.time())
  • JavaScript: Math.floor(Date.now() / 1000) (Note: Date.now() returns milliseconds)
  • Bash: date +%s
  • SQL (PostgreSQL): EXTRACT(EPOCH FROM NOW())

Epoch to human-readable (UTC):

  • Python: datetime.utcfromtimestamp(ts).isoformat()
  • Bash: date -u -d @1750000000 on Linux, date -u -r 1750000000 on macOS

One thing worth knowing: when a timestamp has 13 digits instead of 10, you're looking at milliseconds, not seconds. This trips up more experienced developers than you'd expect. A 10-digit timestamp gets you to somewhere in the early 2030s before it gains an 11th digit; if you see 13 digits today, it's milliseconds.

The Deeper Point About Epoch Design

The Unix timestamp is an object lesson in the value of a shared, fixed reference point over the value of an "optimal" one. January 1, 1970 isn't special. It's just agreed upon — and that agreement, sustained across decades of hardware generations, operating systems, programming languages, and network protocols, has turned a bureaucratic choice into foundational infrastructure.

Every time you look at a log file, check a cookie expiration, or watch an API rate limit reset, you're implicitly interacting with something a group of engineers at Bell Labs decided in a room in New Jersey more than fifty years ago. Second zero isn't a moment of astronomical significance. It's the moment they stopped arguing and started counting.