WorldTimeConverter Logo
WTC
Explainers5 min read

What Is Epoch Time? Unix Timestamps Explained Simply

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."

Right now, the epoch timestamp is somewhere north of 1.78 billion and growing 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 needs to parse both strings, handle timezone offsets, and then compare. With epoch timestamps, it's just: 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.

📊 Unix was created at Bell Labs in 1969–1970, and the choice of January 1, 1970 as the epoch was largely pragmatic — it was a recent, round date that fit comfortably in 32-bit integer storage available at the time. Today, epoch timestamps are used in virtually every programming language, database system, and operating system — National Institute of Standards and Technology (NIST).

Why January 1, 1970?

This is the question almost everyone has.

The short answer: it was arbitrary, but convenient.

Unix was being developed in the early 1970s. The team needed a starting point for their timestamp system. They chose a recent, easily memorable date. January 1, 1970 fit. There's no deep technical reason — they just needed to pick a date and 1970 was recent enough to minimize the range of values they'd be dealing with.

A few alternatives were considered but ruled out: January 1, 1900 (used in some systems) would have required larger numbers to represent modern dates. January 1, 2000 was too far in the future to be useful when Unix was being written in the early 70s.

The choice became the standard because Unix became dominant, and everything else built on top of Unix (or in response to Unix) adopted the same epoch. Now it's too embedded to change.

One practical consequence: 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.

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, 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 — multiply by 1,000 to get a millisecond timestamp. Most other languages and databases use seconds. A 10-digit epoch is seconds. A 13-digit epoch is milliseconds. The epoch converter auto-detects which format you've pasted and handles both.

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-02T17:46: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, 2, 17, 46, 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
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 TIMESTAMP '2026-06-04 14:00:00 UTC')

📊 JavaScript is currently the most widely used programming language in the world, used by over 98% of websites for client-side scripting — Stack Overflow Developer Survey. The JavaScript Date object's millisecond-based timestamps are one of the most common sources of epoch conversion bugs when interfacing with systems that use second-based timestamps.

Common Epoch Timestamps Worth Knowing

These are the milestone values that come up in debugging, testing, and technical discussions:

| Epoch | Human Date (UTC) | Notes | |---|---|---| | 0 | Jan 1, 1970 00:00:00 | The Unix epoch — start of it all | | 1,000,000,000 | Sep 9, 2001 01:46:40 | "Billennium" — widely celebrated by engineers | | 1,234,567,890 | Feb 13, 2009 23:31:30 | Viral moment on tech forums | | 1,500,000,000 | Jul 14, 2017 02:40:00 | One and a half billion seconds | | 2,000,000,000 | May 18, 2033 03:33:20 | Two billion — a future milestone | | 2,147,483,647 | Jan 19, 2038 03:14:07 | Y2K38 — 32-bit signed integer overflow | | 9,999,999,999 | Nov 20, 2286 17:46:39 | Last 10-digit timestamp |

The Y2K38 date is the one developers working on embedded systems or older databases need to care about. For new code written in 2024+, use 64-bit timestamps and you won't see it in your lifetime.

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.

Frequently Asked Questions

What is epoch time in simple terms?

Epoch time is the number of seconds (or milliseconds) since midnight UTC on January 1, 1970. It's a universal way for computers to represent any moment in time as a single integer, without needing to deal with dates, months, or timezones directly.

What is the current epoch timestamp?

It's a live value growing by 1 every second — the epoch time converter shows the current timestamp in real time. As of mid-2026, it's past 1.78 billion.

Is epoch time in seconds or milliseconds?

Both formats exist. Traditional Unix epoch timestamps are in seconds (10 digits). JavaScript and some APIs use milliseconds (13 digits). If you have a 10-digit number like 1780000000, that's seconds. A 13-digit number like 1780000000000 is milliseconds. The converter detects both automatically.

What happens to 32-bit systems in 2038?

On January 19, 2038, 32-bit signed integer timestamps overflow and wrap to a large negative value, which most systems read as December 13, 1901. Modern 64-bit systems handle this correctly — the issue only affects legacy systems that haven't been updated to use 64-bit timestamps.

How do I convert an epoch timestamp to a readable date?

The epoch time converter does this in one step — paste the timestamp, pick your timezone, get the readable date. In code: new Date(timestamp * 1000).toISOString() in JavaScript, datetime.fromtimestamp(ts, tz=timezone.utc) in Python.

Why do some APIs return 13-digit timestamps?

Because they're using milliseconds instead of seconds. JavaScript's Date.now() returns milliseconds by default, and many APIs built with JavaScript backends pass that value through. Divide by 1,000 to get the seconds-based epoch.

Related Articles

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

← All articles