Unix Time Explained — Why Computers Count Seconds Since 1970

Published July 27, 2026 · gworldtime Guides

Under every calendar app, log file, and database there's usually just one big number: the count of seconds since New Year 1970. It's a beautifully simple idea with a few famous sharp edges — including a deadline in the year 2038.

The idea: one number, no calendar

Unix time (or epoch time) represents a moment as the number of seconds elapsed since 00:00:00 UTC on January 1, 1970 — a reference instant called the epoch. As of late July 2026, the counter reads around 1,785,000,000. Some milestones:

Timestamp	Moment (UTC)	Note
0	1970-01-01 00:00	The epoch itself
1,000,000,000	2001-09-09 01:46	The "billennium" — developers threw parties
1,234,567,890	2009-02-13 23:31	Another celebrated oddity
2,147,483,647	2038-01-19 03:14:07	The 32-bit limit — see below

Why 1970? No cosmic reason — Unix was developed at Bell Labs around then, and its creators simply picked a convenient recent round date. The whole computing world inherited the choice.

The key property: no time zones inside

A Unix timestamp identifies an instant, the same one everywhere on Earth. When the counter hit 1,700,000,000, it was 11:38 PM in London and 8:38 AM the next day in Seoul — but the number was identical on every machine. Time zones only enter at the display step, when software converts the number to local text using the IANA rules described in our time zone guide.

This is exactly why engineers love it: store and compare instants as plain numbers, convert to local time only at the last moment for human eyes. It's also why servers log in UTC — a timestamp needs no "which zone?" footnote. When two systems disagree about an event's time, the culprit is almost never the timestamp; it's a wrong conversion or a device clock that isn't properly synchronized.

Seconds or milliseconds? A classic bug

Unix time proper counts seconds, but JavaScript's Date.now() and many APIs count milliseconds. Mixing them up produces two recognizable failure modes:

Treat milliseconds as seconds → dates some 50,000+ years in the future.
Treat seconds as milliseconds → everything happened in January 1970. If you've ever seen "January 1, 1970" or "December 31, 1969" (that's a zero or negative timestamp shifted into a western time zone) in an app, this is the bug you were looking at.

The tell: a seconds timestamp today is 10 digits; milliseconds is 13.

The Year 2038 problem

Old systems store the counter as a signed 32-bit integer, whose maximum value is 2,147,483,647. At 03:14:07 UTC on January 19, 2038, such a counter overflows and wraps to a large negative number — which decodes to December 1901. It's the same species of bug as Y2K, but hiding at a lower level: not in date formatting, but in the storage width of a number inside operating systems, file formats, databases, and embedded chips.

Modern 64-bit systems are safe (a 64-bit counter outlives the Sun by a wide margin), and Linux, databases, and languages have largely migrated. The remaining concern is long-lived embedded hardware — routers, industrial controllers, cars — built years ago and still running in 2038.

What about leap seconds?

Here's the subtle one: official UTC occasionally inserts a leap second, but Unix time pretends it never happened — every day is exactly 86,400 counts, and during a leap second the counter effectively repeats a value. Large operators like Google and Amazon instead "smear" the extra second, running their clocks imperceptibly slower for hours around the event so no software ever sees a repeated timestamp. With leap seconds scheduled for abolition by 2035, this quirk is on its way to becoming history.

Converting timestamps in practice

In a browser console: new Date(1785000000 * 1000) — multiply by 1,000 because JavaScript expects milliseconds; the result prints in your local zone.
On macOS / Linux: date -r 1785000000 (BSD/macOS) or date -d @1785000000 (GNU/Linux).
Getting "now": date +%s in any terminal, or Math.floor(Date.now() / 1000) in JavaScript.
Reading a converted result: remember the output is in some zone — check whether it says UTC or local before you trust the hour. To see what that instant looks like across the world, pin a few cities on the world clock.

One number, every clock

Unix time is the machine view of the same reality the gworldtime globe shows visually: a single universal instant, wearing a different local costume in every city. The globe computes each city's display from a synchronized UTC reference and the IANA rules — which is precisely timestamp → local time, done 337 times at once.

Open the World Clock →