WorldTimeConverter Logo
WTC
Explainers5 min read

What Is Epoch Time? Unix Timestamps Explained Simply

S
Written by Saurabh·Last updated October 18, 2026

Every file on your computer has a "last modified" date. Every database row has a created_at field. Every server log has a timestamp. Behind most of those is a single number: a count of seconds since midnight UTC on January 1, 1970.

That number is epoch time. Also called Unix time, Unix timestamp, or POSIX time. It's been the standard for computer time since the early days of Unix, and it's still the dominant way software systems represent moments in time internally.

Here's what it is, why it works that way, and how to actually use it.

What Is Epoch Time?

Epoch time is the number of seconds that have elapsed since 00:00:00 UTC on January 1, 1970, a point in time called "the Unix epoch."

The current timestamp is above 1.78 billion and grows by 1 every second. The epoch time converter shows the live current value and lets you convert any timestamp in both directions.

Why a number? Because computers are much better at comparing, sorting, and storing integers than they are at parsing human-readable date strings. Is "2026-06-04T14:32:11+05:30" before or after "June 4, 2026 9:02 AM EDT"? A computer has to parse both strings, apply the offsets, and then compare. With epoch timestamps it's one comparison of two integers: is 1780000000 larger than 1779999999? Yes. Done.

Epoch time is timezone-agnostic. The number 1780000000 refers to a single instant in time, the same instant everywhere on Earth. What your local clock shows for that moment depends on your timezone, but the epoch value itself doesn't change.

Why January 1, 1970?

This is the question almost everyone has, and the answer is less tidy than the date. The documented history, as laid out in Signs of Triviality on netmeister.org:

Dennis Ritchie later said, as quoted in Wired, that they wanted "one thing that's not going to overflow for a while" and that "1970 seemed to be as good as any." So the date is a convenience, not a birthday: Unix itself began around 1969.

Other systems picked other starting points. NTP counts from January 1, 1900 and classic Mac OS counted from January 1, 1904. The Unix choice stuck because Unix, C and the languages built on top of them spread everywhere, and now it's too embedded to change.

The practical consequence is the year 2038 problem. The original Unix timestamp was stored as a 32-bit signed integer. 32-bit signed integers max out at 2,147,483,647. When the epoch hits that value, on January 19, 2038 at 03:14:07 UTC, 32-bit systems will overflow. The number wraps around to a large negative value, which most systems interpret as December 13, 1901.

Modern 64-bit systems don't have this problem. A 64-bit signed integer can represent timestamps until the year 292,277,026,596, effectively forever. Most software written in the last decade uses 64-bit timestamps. But legacy embedded systems, older databases, and infrastructure that hasn't been updated are still at risk. If you have a column that stores a 32-bit epoch and the system will still be running in the 2030s, widen it to 64 bits (or a native timestamp type) well before 2038 and backfill, rather than doing it under deadline pressure.

How to Convert Epoch Time to Human-Readable Time

The formula: divide by seconds-per-day, count the days from January 1, 1970, figure out the date. Then handle the remaining seconds for the time.

In practice, nobody does this manually. Every programming language has built-in functions for it.

The epoch time converter converts in both directions. Paste a Unix timestamp, and get a human-readable date in any timezone. Or pick a date and time, get the epoch value back.

Manual conversion for common cases:

One day = 86,400 seconds (24 × 60 × 60)
One hour = 3,600 seconds
One week = 604,800 seconds
One year (non-leap) = 31,536,000 seconds

So if you want to know what time it was 7 days ago: current epoch minus 604,800.

If you want the epoch for "yesterday at noon UTC": today's epoch at noon UTC minus 86,400.

Seconds vs milliseconds: This is the one that causes bugs. JavaScript's Date.now() returns milliseconds, so divide by 1,000 to get seconds. Most other languages and databases use seconds. A 10-digit epoch is seconds and a 13-digit epoch is milliseconds, which is why many APIs built on JavaScript return 13 digits. The epoch converter guesses the unit from the length of the number and shows which one it used.

Epoch Time in Different Programming Languages

JavaScript:

// Current epoch in seconds
Math.floor(Date.now() / 1000)

// Current epoch in milliseconds
Date.now()

// Convert epoch to readable date
new Date(1780000000 * 1000).toISOString()
// → "2026-05-28T20:26:40.000Z"

// Convert readable date to epoch
new Date('2026-06-04T14:00:00Z').getTime() / 1000

Python:

import time
from datetime import datetime, timezone

# Current epoch
int(time.time())

# Convert epoch to readable
datetime.fromtimestamp(1780000000, tz=timezone.utc)
# → datetime(2026, 5, 28, 20, 26, 40, tzinfo=timezone.utc)

# Convert readable to epoch
datetime(2026, 6, 4, 14, 0, 0, tzinfo=timezone.utc).timestamp()

SQL (MySQL):

-- Current epoch
UNIX_TIMESTAMP()

-- Convert epoch to datetime
FROM_UNIXTIME(1780000000)

-- Convert datetime to epoch (the datetime is read in the session time zone)
UNIX_TIMESTAMP('2026-06-04 14:00:00')

SQL (PostgreSQL):

-- Current epoch
EXTRACT(EPOCH FROM NOW())

-- Convert epoch to timestamp
TO_TIMESTAMP(1780000000)

-- Convert timestamp to epoch
EXTRACT(EPOCH FROM TIMESTAMPTZ '2026-06-04 14:00:00+00')

One milestone value worth flagging beyond the well-known ones (the Unix time glossary entry has the fuller table): 9,999,999,999 (Nov 20, 2286) is the last value that fits in 10 digits. After that, every second-based Unix timestamp needs an 11th digit, which is a fun edge case to test against if you're writing date-parsing code that assumes a fixed digit count.

Two Details Worth Knowing

Leap seconds. Unix time treats every day as exactly 86,400 seconds, so it skips leap seconds instead of counting them. For almost all software this makes no difference, but it means Unix time is not an exact count of elapsed seconds since 1970.

Negative values. Timestamps before 1970 are negative: -86400 is December 31, 1969. Most modern systems handle them, and 32-bit systems can go back only to December 13, 1901 (-2147483648).

Epoch Time vs ISO 8601

ISO 8601 is the international standard for representing dates and times in string format: 2026-06-04T14:00:00Z. It's human-readable, timezone-explicit, and unambiguous.

Epoch time is an integer: 1780000000. It's compact, sortable, and fast for computers to work with.

Both have their place:

Most well-designed systems store timestamps as epoch values internally and convert to ISO 8601 (or a localized human-readable format) only at the display layer. This combination gives you the computational efficiency of integers plus the human readability of formatted dates.

How Epoch Time Handles Time Zones

It doesn't, and that's the point.

Epoch time is always in UTC. The number 1780000000 means the same instant everywhere. When you convert it to a human-readable format, you apply a timezone offset at that conversion step. The epoch value itself is timezone-neutral.

This is why epoch timestamps are so useful for distributed systems. A server in Tokyo and a server in New York can both log 1780000000 for the same event, and when you compare the logs, the timestamps align perfectly. If they'd each logged their local time, you'd need to do timezone math to compare them.

What to Do Next

To read or create a timestamp, use the epoch time converter: paste a number to see the date in any zone, or enter a date and get the number back. In code, the current timestamp is Math.floor(Date.now() / 1000) in JavaScript, int(time.time()) in Python, and UNIX_TIMESTAMP() in MySQL. For how to write the same moment as text, see UTC vs GMT and the ISO 8601 entry.

Related Articles

Related glossary terms: What Is Unix Time? · What Is ISO 8601? · What Is UTC?

← All articles