Current Unix time

What is Unix time?

Unix time is a single integer: the number of seconds elapsed since the Unix epoch, 1970-01-01T00:00:00Z. Every modern operating system, database and programming language can produce it, and because it is just a number — no timezone, no calendar, no daylight saving — two systems anywhere in the world agree on what a given Unix timestamp means without ever exchanging locale information.

The panel above renders that one instant five ways at the same time, so whichever field you are filling in has a value ready to copy: the count in seconds, the same count in milliseconds, a UTC date string, the same moment in your local time, and an ISO 8601 string of the form 2026-08-21T09:30:00.000Z. The ISO 8601 rendering is the one to paste into a JSON body or a query string — it carries its own offset, so it needs no separate note about which zone it was written in, and converting an ISO 8601 or RFC 3339 string back to epoch seconds is a round trip with nothing lost.

Why 1970?

The epoch was fixed by Unix's designers at Bell Labs in the early 1970s. It was not chosen for any astronomical or technical reason — it was simply a recent, round date that made early system clocks convenient to initialize. Every timestamp you see today, including the one above, still counts forward from that arbitrary point.

Getting the current Unix timestamp in code

// JavaScript — seconds and milliseconds
const nowSeconds = Math.floor(Date.now() / 1000)
const nowMs = Date.now()

# Python
import time
now_seconds = int(time.time())

# Bash / coreutils
date +%s

-- SQL (Postgres)
SELECT extract(epoch FROM now())::bigint;

All four return the same instant expressed the same way this page displays it — an integer count of seconds (or milliseconds, in JavaScript's case) since the epoch.

Seconds vs. milliseconds

A current Unix timestamp in seconds has 10 digits today and will keep 10 digits until the year 2286. In milliseconds it has 13. Mixing the two up is the single most common Unix-time bug — a seconds value handed to an API expecting milliseconds renders as a date in early 1970, and the reverse overflows into the far future. If you are seeing either of those, the 1970 debugger names the bug and gives you the fix, or run any bare number through the unit detector to see which it is.

Two finer precisions turn up in the same places, and they are the reason the digit count settles the question on its own. Microseconds — 16 digits today — are what PostgreSQL's timestamp columns store, what Python's datetime carries, and what most tracing and metrics systems record. Nanoseconds — 19 digits — are what Go's time.Now().UnixNano(), OpenTelemetry spans and pandas' datetime64[ns] hand back. Nineteen digits is close to the ceiling for this shape of value: a nanosecond epoch in a signed 64-bit integer runs out in the year 2262, which is why nanoseconds are usually the last precision anybody adds and why pandas documents that limit rather than hiding it. Each step is another factor of 1000, so the conversion is always a division and never a parse:

Width in digits is not the same as width in storage, and it is the second one that breaks. Ten digits fit anywhere, but a signed 32-bit column stops counting at 2147483647 — which is why a seconds timestamp runs out in 2038 even though the number itself stays ten digits until 2286. Copying a precision from the panel above is a formatting choice; the column you store the result in is not.

Leap seconds

Unix time treats every day as exactly 86,400 seconds and does not count leap seconds — the occasional extra second inserted to keep clocks aligned with Earth's slightly irregular rotation. When a leap second occurs, Unix time either repeats a second or relies on the operating system to smear it across the surrounding hours. This is a deliberate simplification: it keeps timestamp arithmetic (differences, comparisons, sorting) exact, at the cost of Unix time not being a strictly true count of elapsed seconds since 1970.

Frequently asked questions

What is the current Unix timestamp?

The live number at the top of this page is the current Unix timestamp in seconds, updating every second. It equals the number of seconds since January 1, 1970 00:00:00 UTC.

How is Unix time calculated?

By subtracting the epoch (1970-01-01T00:00:00Z) from the current moment and expressing the difference in whole seconds. In code, JavaScript's Date.now() returns milliseconds, so dividing by 1000 and flooring gives Unix seconds.

Does Unix time account for leap seconds?

No. Unix time assumes every day is exactly 86,400 seconds and ignores leap seconds entirely, repeating or skipping a second on the rare days one is inserted. This keeps the count simple at the cost of not being a true count of elapsed SI seconds.

Why does Unix time start in 1970?

January 1, 1970 was chosen as an arbitrary but convenient epoch by the designers of Unix in the early 1970s — recent enough to be practical, round enough to be memorable. It has no deeper technical meaning.

Where to go next

Need to convert a specific timestamp instead of the current one? Use the full converter. Decoding a JWT's exp claim against the current time? the JWT expiry decoder compares it for you. And because the number above is UTC and nothing else, rendering it as local time in a named zone is a separate step — one this site does with the browser's own DST-aware tz database.