The current Unix timestamp

What this number is

Unix time is a single integer counting the seconds since midnight UTC on 1 January 1970 — the moment conventionally called the epoch. It carries no timezone, no daylight saving, and no formatting decisions, which is exactly why it has outlasted every rival: two systems on opposite sides of the world holding the same timestamp are unambiguously talking about the same instant. Everything human-readable — the date, the weekday, the local time — is derived from it on the way out.

The value above is read from your own machine every second. There is no server call and no network time lookup, so the reading inherits whatever accuracy your device's clock has. On a phone or a laptop syncing to NTP that is typically within a few milliseconds; on a machine whose clock has drifted, this page drifts with it. If you need to check, compare the seconds value here against another device — a disagreement of more than a second or two means something on one of them needs a time sync.

Seconds, or milliseconds?

The same instant is written four ways, and picking the wrong one is the most common bug in date handling. Right now the seconds form is ten digits and the milliseconds form is thirteen, which is the quickest way to tell them apart at a glance:

• Seconds, 10 digits — Unix tools, most REST APIs, Postgres, Go's Unix().
• Milliseconds, 13 digits — JavaScript's Date.now(), Java's currentTimeMillis().
• Microseconds, 16 digits — Postgres internal time, many tracing systems.
• Nanoseconds, 19 digits — Go's UnixNano(), most metrics pipelines.

Hand a seconds value to something expecting milliseconds and your date lands in January 1970, three weeks after the epoch. Send milliseconds where seconds were wanted and you land tens of thousands of years in the future. The nanosecond value deserves particular care: at 19 digits it is already beyond what a JavaScript Number holds exactly, so this page computes it with BigInt and gives it to you as a string.

Getting the current timestamp in code

• Shell: date +%s
• JavaScript: Math.floor(Date.now() / 1000)
• Python: int(time.time())
• Go: time.Now().Unix()
• Java: Instant.now().getEpochSecond()
• PostgreSQL: extract(epoch from now())::bigint

Each of these returns seconds. In JavaScript, dropping the division gives milliseconds; in Python, dropping the int() gives a float with sub-second precision. Both are useful, and both are worth being deliberate about.

The 2038 problem

A signed 32-bit integer tops out at 2,147,483,647, which as a Unix timestamp is 03:14:07 UTC on 19 January 2038. A system still storing time in a 32-bit signed field will wrap to a negative number at that instant and read the date as December 1901. Modern operating systems and languages moved to 64-bit time years ago and will not overflow for around 292 billion years, but the old width survives in embedded firmware, fixed-width binary file formats, and database columns sized when the deadline felt comfortably distant. It is worth knowing which of those you are responsible for, because the fix is much cheaper now than it will be later.

Common questions

What is the Unix timestamp right now?

It is the number of seconds that have elapsed since midnight UTC on 1 January 1970, and it is currently a ten-digit number beginning with 17. The clock at the top of this page reads it live from your own machine and advances every second, so the value you copy is the value at the moment you copy it. Because the count is defined against UTC, everyone reading this page anywhere in the world sees the same number at the same instant — that is the entire appeal of the format, and the reason nearly every system stores time this way rather than as a date.

Is this reading from your server or my computer?

Your computer. The page ships no clock of its own; it calls the browser's Date.now() and formats the result, which means the number is exactly as accurate as your device's clock and nothing is sent to or requested from a server. If your machine's clock is wrong, this page is wrong in precisely the same way, and comparing it against a phone or another computer is a quick way to notice that your system time has drifted.

Why does the timestamp stop when I press freeze?

Copying a moving number is a small trap: by the time you paste it, it names a moment that has already passed, and if you are pasting it into a test fixture or a bug report you usually want a stable value rather than the true current instant. Freezing holds the reading still so every field on the page keeps describing the same moment, and the copy buttons keep working exactly as before. Nothing is lost — pressing it again resumes from the real clock, not from where the display stopped.

What happens in 2038?

A signed 32-bit integer runs out at 03:14:07 UTC on 19 January 2038, at 2,147,483,647 seconds. Any system still storing time in a 32-bit signed field will wrap to negative and read the date as December 1901. Modern platforms use 64-bit time and are unaffected — that will not overflow for roughly 292 billion years — but the problem persists in embedded firmware, old file formats, and database columns that were sized decades ago. It is worth knowing which of those you own.

Does the count include leap seconds?

No, and this is a genuine oddity rather than a bug. Unix time is defined as if every day contains exactly 86,400 seconds, so a leap second is not counted — the timestamp either repeats a value or is smeared across a period, depending on the platform. The practical consequence is that a Unix timestamp is not a true count of elapsed physical seconds since 1970; it is a count of nominal days, which is what makes converting it back to a date so simple. For everything short of precision timekeeping, the distinction does not matter.

How do I get this number in my own code?

In JavaScript, Math.floor(Date.now() / 1000); in Python, int(time.time()); in Go, time.Now().Unix(); in Java, Instant.now().getEpochSecond(); in PostgreSQL, extract(epoch from now())::bigint; and at a Unix shell, date +%s. Each returns seconds. Drop the division in JavaScript and you get milliseconds instead, which is the single most common unit mix-up in date handling — check what your target expects before you send it.