Unix Timestamp Converter
The live Unix epoch plus conversion both ways, in seconds or milliseconds, UTC and local.
Unix Timestamp Converter tool
The time right now
This moment in other formats
| UTC | — | |
|---|---|---|
| Local time | — | |
| ISO 8601 | — | |
| RFC 2822 | — | |
| Microseconds | — | |
| ISO week / day of year | — |
Your clock reads —. The value comes from this device, so it is only as accurate as your system clock.
Timestamp to date
| Detected unit | — | |
|---|---|---|
| UTC | — | |
| Local time | — | |
| ISO 8601 (UTC) | — | |
| ISO 8601 (local offset) | — | |
| RFC 2822 | — | |
| Relative | — | |
| Epoch seconds | — | |
| Epoch milliseconds | — | |
| ISO week / day of year | — |
Date to timestamp
What this tool does
A Unix timestamp counts the seconds elapsed since 00:00:00 UTC on 1 January 1970, ignoring leap seconds. That makes it compact and unambiguous for machines and completely unreadable for people. This page covers all three things you normally want from one: what the epoch is at this moment, what a given timestamp means, and what a given date is as a timestamp.
At the top, the current epoch ticks live in seconds and milliseconds. Press Pause to freeze it so a value cannot change between reading it and pasting it — both copy buttons keep working while paused — or Convert this timestamp to drop the current value straight into the converter below.
The middle section takes any timestamp and shows the instant it represents in UTC, in your own zone, and in the string formats you are most likely to paste back somewhere else. The last section runs the other way: pick a date and time, say whether you mean it locally or in UTC, and read off the epoch value.
Common uses
- Reading a log line. Structured logs from Go, Java and most observability pipelines emit raw epoch values, often in milliseconds or nanoseconds.
-
Checking a JWT. The
exp,iatandnbfclaims are epoch seconds — pastingexphere tells you at a glance whether a token has already expired. -
Building a fixture. A test that needs a stable "yesterday" wants a literal number, not
Date.now(). - Comparing a database column against an API response when one stores seconds and the other milliseconds.
A short example
The value 1700000000 resolves to:
UTC 2023-11-14 22:13:20
ISO 8601 2023-11-14T22:13:20.000Z
RFC 2822 Tue, 14 Nov 2023 22:13:20 +0000
Epoch ms 1700000000000How the unit is detected
The unit is inferred from the digit count, which is exact rather than a guess for anything recorded this century. Since 9 September 2001 every timestamp in seconds has had 10 digits and every timestamp in milliseconds 13, and that stays true until November 2286. So:
- up to 11 digits — seconds
- 12 to 14 digits — milliseconds
- 15 to 17 digits — microseconds, as PostgreSQL and ClickHouse emit
- 18 or more — nanoseconds, as Go's
UnixNanoand OpenTelemetry emit
The cutoff sits at 12 digits because 100,000,000,000 seconds is the year 5138 — a value no real system produces — whereas the same number of milliseconds is 1973. The detected unit is always shown, and the dropdown overrides it. Nanosecond values exceed the 253 limit of a JavaScript number, so they are converted with BigInt and any sub-millisecond remainder is reported rather than quietly discarded.
Worth knowing
Unix time is not a count of every second that has passed. Leap seconds are absorbed by
repeating a value, so the 27 inserted since 1972 are invisible here — which is precisely
why the format is easy to compute with. Negative values are legal and mean dates before
1970. And the year 2038 limit belongs to the 32-bit signed integer, not to the epoch
itself: at 03:14:07 UTC on 19 January 2038 a time_t of that width overflows
to 1901. Anything storing 64 bits is fine for the next 292 billion years.
Frequently asked questions
How do I tell seconds from milliseconds?
A present-day timestamp in seconds has 10 digits; in milliseconds it has 13. This tool detects the likely unit automatically and tells you which one it used, so a millisecond value is never silently read as the year 56000.
What is the year 2038 problem?
Systems that store Unix time in a signed 32-bit integer overflow on 19 January 2038. Any modern language using 64-bit integers is unaffected, but legacy C code and some embedded databases still are.
Does a Unix timestamp depend on my timezone?
No. The count is the same integer in Auckland as in Los Angeles; only the rendering of it changes. So when two systems differ by exactly 3,600 or 19,800, that is not a timezone living inside the number — it is one side converting a wall-clock reading as though it were already UTC. MySQL is a frequent culprit: TIMESTAMP columns are converted using the session time_zone, DATETIME columns are not.
Does Unix time count leap seconds?
It does not. POSIX defines every day as exactly 86,400 seconds, so the 27 leap seconds inserted since 1972 are simply absent and the count now trails elapsed atomic time by that much. Rather than repeat a second and risk a clock going backwards, Google and AWS spread it across a 24-hour smear. The General Conference on Weights and Measures voted in 2022 to stop adding them by 2035.
How do I get the current timestamp in code?
In whole seconds: date +%s in a shell, time.time() in Python, time() in PHP, EXTRACT(EPOCH FROM now()) in PostgreSQL, UNIX_TIMESTAMP() in MySQL, time.Now().Unix() in Go. JavaScript and Java are the outliers that hand back milliseconds — Date.now() and System.currentTimeMillis() — and that mismatch is where most unit confusion between a front end and its database begins.