What is a Unix timestamp?
The number of seconds since 00:00:00 UTC on 1 January 1970, not counting leap seconds. That instant is the epoch, and the count is a single integer with no time zone attached, which is exactly what makes it useful: the same moment has the same timestamp in London, Tokyo and on a server with its clock set wrong.
Negative values work and mean dates before 1970, so -86400 is 31 December 1969. The absence of leap seconds is deliberate rather than an oversight: every day in Unix time is exactly 86,400 seconds long, which keeps the arithmetic simple at the cost of drifting a handful of seconds from astronomical time.
Is my timestamp in seconds or milliseconds?
Count the digits. A present-day timestamp is 10 digits in seconds, 13 in milliseconds and 16 in microseconds.
| Unit | Digits today | Example | Where you meet it |
|---|---|---|---|
| Seconds | 10 | 1700000000 | Unix tooling, most APIs, JWT exp, Postgres to_timestamp |
| Milliseconds | 13 | 1700000000000 | JavaScript Date.now(), Java, Kafka |
| Microseconds | 16 | 1700000000000000 | Postgres internal timestamps, ClickHouse, some tracing |
| Nanoseconds | 19 | 1700000000000000000 | Go UnixNano(), Prometheus, InfluxDB |
This converter reads the unit from the size of the number, which is right almost always and wrong for dates far from the present. If you are converting something in 1971 or 2300, set the unit by hand rather than trusting the guess.
What is the year 2038 problem?
A signed 32-bit integer stops at 2,147,483,647, which as a count of seconds is 03:14:07 UTC on 19 January 2038. One second later it overflows to a large negative number, and anything still storing time that way reads the date as December 1901.
Most current systems use 64-bit time, which pushes the limit roughly 292 billion years out and makes the problem moot. It survives in embedded firmware, old database columns, file formats with a fixed 32-bit field, and any code that casts a timestamp to int without thinking. Paste 2147483647 above and then add one to see it.
How do I convert epoch to a date in code?
| Language or tool | Timestamp to date | Date to timestamp |
|---|---|---|
| JavaScript | new Date(ts * 1000) | Math.floor(Date.now() / 1000) |
| Python | datetime.fromtimestamp(ts, timezone.utc) | int(datetime.now(timezone.utc).timestamp()) |
| PostgreSQL | to_timestamp(ts) | extract(epoch from now()) |
| MySQL | from_unixtime(ts) | unix_timestamp() |
| bash (GNU) | date -d @1700000000 | date +%s |
| bash (macOS) | date -r 1700000000 | date +%s |
| Go | time.Unix(ts, 0) | time.Now().Unix() |
| Excel | =ts/86400+25569, formatted as a date | =(A1-25569)*86400 |
Common questions
Why does my timestamp show a different time than my colleague's?
Because a timestamp has no time zone and a displayed date does. The same integer is one instant; rendering it produces different wall-clock times depending on whose zone it is rendered in. The two rows above show the same timestamp in UTC and in your own zone, which is usually enough to settle the argument. If one of you is also an hour out across part of the year, that is daylight saving rather than a bug.
Why did my 10/11/2025 come out as October?
Because that is what Date.parse does. JavaScript reads a slash-separated date month first, a US convention, so 10/11/2025 becomes 10 October and 13/11/2025 is rejected as having no thirteenth month. This converter reads separated dates day first instead, which is how they are written in the UK, and tells you when the other reading is also a valid date so you can switch to it. Typing an ISO date such as 2025-11-10 removes the ambiguity entirely, which is the reason ISO 8601 orders its fields largest first.
Need the other direction of network arithmetic? The CIDR calculator works out subnet boundaries, masks and host counts.