Unix Time Explained: What Every Developer Should Know

Unix time (also called epoch time, POSIX time, or Unix timestamp) is the number of seconds that have elapsed since January 1, 1970 at 00:00:00 UTC. This reference point is called the Unix epoch.

The Unix epoch was chosen for the original Unix operating system developed at Bell Labs in the early 1970s. The exact date was selected because it was a round number that predated any production Unix deployment, and because the 1970 boundary was far enough in the past to represent historical dates while still fitting in available integer storage.

As of early 2026, the current Unix timestamp is approximately 1,760,000,000 seconds. You can verify this on our Unix Timestamp Converter.

Storing time as a single integer is dramatically simpler than storing a date/time string. Consider what it would take to compare two calendar timestamps: you'd need to account for month lengths, leap years, leap seconds, timezone offsets, and DST rules. Unix time reduces all of this to a simple integer comparison.

Unix timestamps have three key advantages:

• →Timezone-agnostic: Unix time is always in UTC. Converting to a local time is a display concern, not a storage concern. This means a timestamp written in Tokyo and read in New York refers to the same absolute moment.
• →Mathematically simple: Adding 86,400 seconds to a Unix timestamp advances it by exactly one day. Computing the difference between two timestamps is a single subtraction. No calendrical arithmetic required.
• →Universally supported: Every programming language, database, and operating system understands Unix time. The POSIX standard mandates it. Interoperability between systems is trivial.

The original Unix timestamp counts seconds. In 2026, a seconds-based Unix timestamp is a 10-digit number (e.g., 1760000000).

However, many modern systems — particularly JavaScript, Java, and databases like MongoDB — store time in milliseconds. A milliseconds-based timestamp is a 13-digit number (e.g., 1760000000000).

A common bug: receiving a 13-digit milliseconds timestamp and treating it as seconds, which produces dates in the year 57,000+. Always check the digit count when working with unknown timestamp sources. If you see a 13-digit value, divide by 1000 to get seconds.

Converting between Unix time and human-readable dates in common languages:

// Unix timestamp → Date
const date = new Date(1704067200 * 1000); // multiply by 1000 for ms
console.log(date.toISOString()); // "2024-01-01T00:00:00.000Z"

// Date → Unix timestamp (seconds)
const ts = Math.floor(new Date('2024-01-01').getTime() / 1000);
console.log(ts); // 1704067200

from datetime import datetime, timezone

# Unix timestamp → datetime (UTC-aware)
dt = datetime.fromtimestamp(1704067200, tz=timezone.utc)
print(dt)  # 2024-01-01 00:00:00+00:00

# datetime → Unix timestamp
ts = int(datetime(2024, 1, 1, tzinfo=timezone.utc).timestamp())
print(ts)  # 1704067200

-- Unix timestamp → timestamptz
SELECT to_timestamp(1704067200);
-- Returns: 2024-01-01 00:00:00+00

-- Current timestamptz → Unix timestamp
SELECT EXTRACT(EPOCH FROM NOW());

The year 2038 problem (also called Y2K38 or the Unix millennium bug) is a time representation issue that will affect systems using a signed 32-bit integer to store Unix timestamps.

A signed 32-bit integer can hold values from −2,147,483,648 to 2,147,483,647. The maximum value, 2,147,483,647, in seconds after the Unix epoch, corresponds to January 19, 2038 at 03:14:07 UTC. One second after that, the integer overflows to the most negative value, −2,147,483,648, which represents December 13, 1901 — flipping time backward by 136 years.

Systems affected include any software compiled for 32-bit architectures that stores time as a 32-bit signed integer: older embedded systems, legacy SCADA and industrial control systems, some file systems, and certain database implementations. Modern 64-bit systems are not affected — a 64-bit signed integer can hold Unix timestamps until approximately the year 292 billion.

The good news: most consumer software and cloud infrastructure migrated to 64-bit architectures years ago. The risk area is embedded systems with decades-long deployment lifespans — medical devices, automotive control systems, infrastructure monitoring, and industrial equipment installed in the early 2000s that may still be running in 2038.

Dates before January 1, 1970 are represented as negative Unix timestamps. For example:

Not all systems support negative Unix timestamps. Windows historically had issues with pre-1970 dates. When working with historical dates in software, verify that your runtime and database correctly handle negative epoch values before relying on them.