Try explaining to a computer that something happened on "July 4, 2026, at 3:30 PM." Immediately you run into problems: which time zone? Daylight saving or standard time? Which calendar? A human understands the context, but a computer needs an unambiguous number.

That is why Unix systems use a single integer: the number of seconds since 1970-01-01 00:00:00 UTC. That starting moment is called the Unix epoch. As I write this, the counter is somewhere past 1.78 billion and still ticking.

Why 1970?

Unix was being developed at Bell Labs in the late 1960s and early 1970s. The first Unix Programmer's Manual came out in 1971. When the developers needed a reference point for timestamps, they picked the earliest clean, round date near the birth of the system itself.

January 1, 1970, was not chosen for any historical significance. It was convenient. Some early Unix versions actually used 1971-01-01, but Ken Thompson and Dennis Ritchie settled on 1970 as Unix spread across different machines. The date stuck because Unix became ubiquitous, and every system that inherited Unix's timekeeping — Linux, macOS, BSD, Android, most embedded devices — carried the same epoch forward.

It is one of those decisions made over fifty years ago that we are all still living with.

What the Number Actually Represents

The current Unix timestamp in seconds is around 1,784,000,000. Physically, it is an integer stored in the system's clock hardware or kernel. On modern systems it is 64-bit, giving enough range to count billions of years. On older 32-bit systems it overflows on January 19, 2038.

Here is what that looks like conceptually:

Unix Epoch                Now (2026)               2038 Problem
   |                         |                         |
   v                         v                         v
1970-01-01 00:00:00 UTC  ~1,784,000,000 seconds    2,147,483,647
   |<------------------------>|<----------------------->|
   0                         +1.78 billion           overflow

Every file modification time, log entry, database created_at field, and API timestamp starts as one of these integers. The conversion to a readable date happens so fast that we never think about it — but the integer is always underneath.

From Timestamp to Date

Converting a timestamp back to a date is mostly division:

Seconds in a minute: 60
Seconds in an hour:  3,600
Seconds in a day:    86,400
Seconds in a year:   ~31,557,600

With the timestamp 1,719,792,000, you divide by 86,400 to get the number of days since the epoch, then map that to a calendar date. The result is 2024-07-01 00:00:00 UTC.

In Python, the standard library hides all that math:

import time

now = time.time()
print(int(now))  # Current timestamp

readable = time.strftime('%Y-%m-%d %H:%M:%S UTC', time.gmtime(now))
print(readable)

You could build the calendar logic from scratch — counting leap years and month lengths — but almost nobody does. That is the benefit of a universal standard.

Where You Encounter Epoch Time

You interact with Unix timestamps more often than you realize:

File timestamps — Every file on Linux or macOS has mtime, ctime, and atime values stored as timestamps. Run stat filename and you will see them.

Web cookies — Cookie expiration dates are stored as timestamps. If you see a cookie expiring on "January 19, 2038," someone probably used a default max value that wraps on 32-bit systems.

Database records — Most created_at and updated_at columns store timestamps internally, either as integers or native date types that trace back to the same epoch.

API responses — When a REST API returns { "created_at": 1719792000 }, that is a Unix timestamp in seconds. The frontend multiplies by 1000 for JavaScript's Date object.

Blockchain blocks — Block headers contain Unix timestamps. The Bitcoin network uses them to validate transaction order.

The 2038 Problem

A signed 32-bit integer tops out at 2,147,483,647. When the Unix timestamp reaches that value on January 19, 2038, at 03:14:07 UTC, the next second wraps to -2,147,483,648 — which represents December 13, 1901.

The original Unix developers used 32-bit integers because memory was expensive in the 1970s, and 64-bit systems did not exist for general use. The assumption was that these systems would be replaced long before 2038.

Most modern systems use 64-bit timestamps, which will not overflow for about 290 billion years. The real risk is embedded systems, IoT devices, and legacy codebases that are hard to update. We cover this in more detail in the guide to the 2038 problem.

Using an Epoch Converter

You do not need to do the math yourself. Paste a number like 1719792000 into an epoch converter and it shows you the date in local time and UTC. Going the other direction — date to timestamp — works the same way.

I use epoch converters most often when:

  • A log file contains raw timestamps and I need to know when an event happened
  • I need to verify a date boundary, like the start of a month
  • I am checking whether a stored value looks reasonable

For quick conversions, the FastUnix Timestamp Converter handles both seconds and milliseconds in the browser.

A Few Epoch Trivia

  • At 1234567890 — February 13, 2009, at 23:31:30 UTC — some people celebrated the "epoch palindrome."
  • The first billion seconds after the epoch arrived on September 9, 2001, at 01:46:40 UTC.
  • A timestamp of 0 is often used as a sentinel meaning "no date" or "unknown date." If you see 0 in a log, it usually means the field was never set.
  • Older Mac filesystems (HFS+) count seconds since January 1, 1904, while Unix timestamps on macOS use 1970. That mismatch has caused more than a few late-night debugging sessions.

Conclusion

The Unix epoch — 1970-01-01 00:00:00 UTC — is one of those invisible foundations of modern computing. It is a simple idea: count the seconds from a fixed starting point, store the count as an integer, and calculate human-readable dates only when you need to display them.

Next time you see a timestamp like 1719792000, you will know it is not just a random number. It is the number of seconds since Unix decided to start the clock.