Timestamp Converter

A Unix timestamp (also called epoch time or POSIX time) is the number of seconds elapsed since 00:00:00 UTC on January 1, 1970 — the "Unix epoch". It's the standard way computers store points in time because it's a single integer that's unambiguous across timezones: 1767225600 means exactly the same moment everywhere on Earth.

Count the digits. Current dates are 10 digits in seconds (≈1.7 billion) and 13 digits in milliseconds. JavaScript's Date.now() and Java's System.currentTimeMillis() return milliseconds; most Unix tools, PHP's time() and Python's time.time() use seconds. Some systems go further: 16 digits are microseconds, 19 digits nanoseconds (Go's UnixNano). This converter auto-detects the unit from the digit count.

Systems that store Unix time as a signed 32-bit integer overflow on January 19, 2038 at 03:14:07 UTC (timestamp 2,147,483,647) — one second later the value wraps to a date in 1901. Modern 64-bit systems are unaffected (good until ~292 billion years), but embedded devices, old file formats and legacy databases with 32-bit time fields can still be bitten.

No. Unix time pretends every day has exactly 86,400 seconds. When a leap second is inserted into UTC, Unix time either repeats a second or smears it across the day (Google and AWS smear). This means Unix time is not a true count of elapsed SI seconds — but for virtually all application purposes that's a feature, not a bug: the math stays simple.

They don't — and that's the point. A Unix timestamp is always UTC-based; timezones only appear when you format it for humans. The same 1767225600 renders as 00:00 in London and 02:00 in Vilnius. Store timestamps (or ISO 8601 with offset) in your database and convert to the user's timezone only at display time — most timezone bugs come from breaking this rule.

Yes — negative values count backwards from the 1970 epoch. -86400 is December 31, 1969. Dates before 1970 are perfectly representable, which matters for birthdates and historical data. Some languages and databases handle negative epochs poorly though, so test before relying on it.

RFC 3339 is essentially a strict profile of ISO 8601 for internet timestamps: 2026-08-24T09:30:00Z or with an offset like +02:00. ISO 8601 additionally allows week dates, ordinal dates, and omitting parts. For APIs, emit RFC 3339 with an explicit offset (or Z for UTC) — it sorts lexicographically and every language parses it.