Current Unix epoch · seconds since 1970-01-01T00:00:00Z
1786576796
ms 1786576796866
·
µs 1786576796866254
·
2026-08-12T23:19:56Z
Device clock: checking…
Convert a timestamp or a date the unit is detected from the digit count
Digit counts, decoded
| Digits | Unit | Example | Where you see it |
|---|---|---|---|
| 10 | seconds | 1735689600 | Unix time(), Postgres epoch, most APIs |
| 13 | milliseconds | 1735689600000 | JavaScript Date.now(), Java, Kafka |
| 16 | microseconds | 1735689600000000 | Python time_ns()/1000, Postgres internal, Chrome |
| 19 | nanoseconds | 1735689600000000000 | Go UnixNano(), InfluxDB, Rust |
URL API bookmarkable, scriptable, documented
| URL | Does |
|---|---|
| /unix-timestamp?t=1735689600 | Convert a value, unit auto-detected. |
| /unix-timestamp?t=1735689600&unit=ms | Force the unit: s, ms, us or ns. |
| /unix-timestamp?t=…&zone=Asia/Tokyo | Add a third column in any IANA zone. |
| /timestamp/1735689600 | A permanent, shareable page for that instant. |
| /api/convert?t=…&to=Asia/Tokyo | The same thing as JSON, keyless. Docs. |
Unix time questions
What is a Unix timestamp?
The number of seconds elapsed since 1970-01-01T00:00:00Z, not counting leap seconds. It has no timezone: the same integer means the same instant everywhere, which is why it is the safest way to move a point in time between systems.
Is my timestamp in seconds, milliseconds or nanoseconds?
Count the digits. Ten digits is seconds and lands in the present; thirteen is milliseconds (JavaScript, Java); sixteen is microseconds (Python time.time_ns()/1000, Postgres); nineteen is nanoseconds (Go, Rust, InfluxDB). The converter above detects the unit for you and shows which one it picked — if a date comes out in 1970 you fed milliseconds to a seconds parser, and if it comes out in the year 50000-plus you did the reverse.
What is the year 2038 problem?
A signed 32-bit integer runs out at 2038-01-19T03:14:07Z. Systems still storing timestamps in an int32 will wrap to 1901 one second later. Anything using a 64-bit integer is fine for the next 292 billion years; the risk lives in embedded devices, old file formats and database columns typed as int rather than bigint.
Do Unix timestamps account for leap seconds?
No. Unix time pretends every day has exactly 86,400 seconds, so a leap second is absorbed by repeating or smearing a value rather than adding one. That is a feature for arithmetic and a trap for anyone measuring true elapsed duration across a leap second — use a monotonic clock for that.
Should I store dates as timestamps or as ISO 8601 strings?
Store an instant as a timestamp (or a timestamptz column) when you need arithmetic, ordering and compact storage. Store ISO 8601 when a human will read the value or when the original offset matters — a timestamp cannot tell you that a meeting was booked as 09:00 in Berlin. Never store local time with no offset at all.