Unix Timestamp Converter
Paste a Unix timestamp to get the date in UTC, your timezone, and every other epoch unit — or go the other way.
Seconds, milliseconds, microseconds, or nanoseconds — the unit is detected from the magnitude.
ISO 8601 (UTC) 2026-08-12T09:30:00.000Z
Epoch seconds 1786527000
Runs entirely in your browser. Nothing you paste here is uploaded, logged, or sent to analytics.
Which unit is my timestamp in?
A bare number is ambiguous — 1786527000 is a valid instant whether you read it
as seconds, milliseconds, or nanoseconds. The tool picks by magnitude, which is what every
epoch converter does, and always shows you which unit it used so you can override it:
| Digits | Read as | Typical source |
|---|---|---|
| 10 or fewer | Seconds | Unix time(), PHP time(), Go Unix(), Postgres extract(epoch …) |
| 13 | Milliseconds | JavaScript Date.now(), Java currentTimeMillis() |
| 16 | Microseconds | Python time.time_ns() / 1000, Postgres internal timestamps |
| 19 | Nanoseconds | Go UnixNano(), Python time.time_ns() |
The rule is exact: below 1e11 is seconds, below 1e14 is milliseconds, below 1e17 is microseconds, and anything larger is nanoseconds. Those boundaries mean any date between 1973 and the year 5138 reads correctly in each unit.
Getting the current timestamp in your language
| Language | Seconds | Milliseconds |
|---|---|---|
| JavaScript | Math.floor(Date.now() / 1000) | Date.now() |
| Python | int(time.time()) | int(time.time() * 1000) |
| PHP | time() | (int)(microtime(true) * 1000) |
| Go | time.Now().Unix() | time.Now().UnixMilli() |
| Java | Instant.now().getEpochSecond() | System.currentTimeMillis() |
| MySQL | UNIX_TIMESTAMP() | UNIX_TIMESTAMP() * 1000 |
| PostgreSQL | EXTRACT(EPOCH FROM now())::bigint | (EXTRACT(EPOCH FROM now()) * 1000)::bigint |
| Shell | date +%s | date +%s%3N (GNU coreutils) |
Things that bite
- The epoch has no timezone. A Unix timestamp is an absolute instant — it is always UTC-based. "Converting a timestamp to another timezone" only changes how it is displayed, never the underlying number.
- The 2038 problem is real for 32-bit signed storage.
2147483647(2038-01-19T03:14:07Z) is the largest value a signed 32-bit integer holds. MySQL'sTIMESTAMPcolumn type still has this ceiling;DATETIMEdoes not. - Unix time is not a count of elapsed SI seconds. It ignores leap seconds by definition (POSIX), so the difference between two timestamps is off by the number of leap seconds inserted between them — 27 since 1972. This matters for precise interval arithmetic and essentially never for application code.
- Negative timestamps are valid and represent dates before 1970. Plenty of libraries mishandle them; this one does not.