Current Unix time: —
Accepts seconds (10 digits) or milliseconds (13 digits) — auto-detected.
A Unix (epoch) timestamp is the number of seconds since 00:00:00 UTC on 1 January 1970. It's a compact, timezone-independent way to store a moment in time. Some systems use milliseconds (13 digits) instead of seconds (10 digits).
The fastest way to tell which unit you are holding is to count the digits. For any date in the current era:
| Unit | Digits | Typical source |
|---|---|---|
| Seconds | 10 | date +%s, Python time.time(), most REST APIs |
| Milliseconds | 13 | JavaScript Date.now(), Java System.currentTimeMillis() |
| Microseconds | 16 | Postgres internals, some tracing formats |
| Nanoseconds | 19 | Go time.Now().UnixNano(), Prometheus exports |
Get it wrong in one direction and your date lands in 1970; get it wrong in the other and you are somewhere in the year 55,000. Both are obvious once you look — which is why an absurd date is almost always a unit mismatch rather than corrupt data.
A timestamp has no timezone. It identifies a moment, not a wall-clock reading. The timezone only enters when you format it for display. Converting local time to epoch as though it were UTC is the most common way timestamps get silently corrupted, and it is invisible until someone in another timezone looks.
Leap seconds don't exist here. Unix time treats every day as exactly 86,400 seconds, so it quietly skips leap seconds rather than counting them. For anything short of scientific timekeeping this is what you want, but it means epoch differences are not true elapsed physical seconds.
2038 is a real deadline. A signed 32-bit seconds counter overflows at 03:14:07 UTC on 19 January 2038. Anything still storing time in a 32-bit integer — embedded devices, old database columns, file formats — needs to move to 64-bit before then.
Negative timestamps are legal. Dates before 1970 are represented as negative numbers. Some parsers reject them, so birthdates and historical records are a common source of surprise failures.
| Environment | Timestamp to date | Now, as epoch |
|---|---|---|
| Shell (GNU) | date -u -d @1700000000 | date +%s |
| Python | datetime.fromtimestamp(ts, tz=timezone.utc) | time.time() |
| JavaScript | new Date(ts * 1000).toISOString() | Date.now() / 1000 |
| Postgres | to_timestamp(1700000000) | extract(epoch from now()) |
It was a convenient recent round date when early Unix systems needed an origin, and it stuck. There is nothing special about it beyond convention, and other systems use other epochs — which is exactly why cross-system timestamp bugs happen.
For a moment in time — when something happened — either works, and epoch integers are compact and unambiguous. For a future wall-clock event such as "09:00 local time next March", store the local time and the timezone name instead. Timezone rules change, and an epoch value locked in today may point at the wrong local hour by then.