What Is Unix Time? The Epoch Explained for Developers

The one-sentence definition

A Unix timestamp is the number of seconds that have elapsed since January 1, 1970, 00:00:00 UTC — a moment called the Unix epoch — with leap seconds ignored. That single integer identifies one exact instant anywhere on the planet. Right now, as you read this, the count is somewhere around 1.79 billion and climbing by one every second.

Three details in that definition do more work than they look like:

• "Number of seconds" — a timestamp is a count, not a clock reading. It has no timezone, no calendar month, no a.m./p.m. Those are all things humans add later, when they format the number.
• "Since January 1, 1970" — that is the reference point. Change the reference point and the same number means a different moment, which is exactly why the snowflake, LDAP, GPS, and NTP formats on this site all exist: they count from different epochs.
• "Leap seconds ignored" — by definition every Unix day is exactly 86,400 seconds long, so the count stays a plain linear counter even though real days occasionally stretch to 86,401 seconds.

Why 1970?

The choice is historical. Unix's earliest surviving documentation, the First Edition manual from 1971, described time as sixtieths of a second since January 1, 1971. As the system matured, the representation was simplified to whole seconds and the reference point settled on midnight at the start of 1970, which was a clean, memorable boundary for the era. The epoch was eventually standardized in POSIX, and because virtually every operating system, database, and language adopted the same convention, one number now means the same instant across the entire industry.

The epoch itself — 0 — is the only timestamp you should recognize instantly: it is January 1, 1970, 00:00:00 UTC, the moment Unix time began.

What a timestamp is not

The most common source of confusion is treating a timestamp like a local clock reading. It is not one. The timestamp 1722750000 is the same instant whether you format it in Tokyo, London, or New York — it reads 05:40:00 on August 4, 2024 in UTC, 14:40 in Tokyo (Asia/Tokyo, UTC+9), 06:40 in London that summer, and 01:40 in New York. Timezones only change how the instant is displayed; they never change the number.

This is why logs, databases, and APIs store timestamps instead of date strings: a timestamp is unambiguous across machines and timezones, compares cleanly with > and <, and sorts chronologically with no parser in sight.

Seconds, milliseconds, and beyond

The POSIX definition counts seconds, but real systems rarely agree on the unit. JavaScript's Date.now() and Java's System.currentTimeMillis() count milliseconds; Go's time.Now().UnixMicro() counts microseconds; Python's time.time() returns fractional seconds. The count itself is always the same elapsed time — only the scale changes:

• 1722750000 — seconds (10 digits).
• 1722750000123 — milliseconds (13 digits).
• 1722750000123456 — microseconds (16 digits).

All three represent August 4, 2024 05:40:00 UTC. Because the scale is easy to get wrong and hard to spot by eye, the Unix timestamp to date converter auto-detects the unit from the number of digits — and lets you override it when a value is ambiguous.

Reference timestamps worth memorizing

A few round numbers make excellent landmarks when you are staring at a log. If a value is near one of these, you instantly know the era you are looking at:

• 0 → January 1, 1970 00:00:00 UTC — the epoch.
• 1000000000 → September 9, 2001 01:46:40 UTC — the first billion.
• 1500000000 → July 14, 2017 02:40:00 UTC.
• 1600000000 → September 13, 2020 12:26:40 UTC.
• 1700000000 → November 14, 2023 22:13:20 UTC.
• 1767225600 → January 1, 2026 00:00:00 UTC — the last New Year so far.
• 2147483647 → January 19, 2038 03:14:07 UTC — the 32-bit limit.

The common Unix timestamps reference keeps a fuller table of famous values, including launch dates, birthdays, and system-anniversary timestamps.

Why the year 2038 matters

If a system stores its timestamps in a signed 32-bit integer, the largest value it can hold is 2,147,483,647 — which is reached on January 19, 2038 at 03:14:07 UTC. One second later the counter overflows into negative numbers, and dates suddenly read as 1901. This is the famous Year 2038 problem, the sequel to the Y2K bug. Modern 64-bit systems count in seconds until roughly the year 292 billion, so for practical purposes the problem is solved everywhere time_t is 64-bit — but it still lurks in embedded devices, old file formats, and protocols that never grew. The site keeps a live countdown to the exact overflow moment.

Reading a timestamp in practice

When you meet a raw number in a log, the fastest path is:

1. Count the digits — 10 is seconds, 13 is milliseconds, 16 is microseconds.
2. Paste it into the converter (or the timestamp-to-date page) and read the UTC row first.
3. If you need the local time, pick your timezone from the list — the instant never changes, only its rendering.

If you regularly decode timestamps from server output, the follow-up guide, How to Read Unix Timestamps in Logs, Fast, covers the shell one-liners and log contexts that make the habit painless.

Beyond Unix time

Unix time is one counting scheme among many. GPS satellites count from 1980 and ignore the same leap seconds differently; Active Directory counts 100-nanosecond ticks from 1601; Discord packs a millisecond timestamp inside a 64-bit ID. Each has its own converter on this site — the leap seconds guide and the Windows formats guide are good places to start comparing them.