Unix time counts seconds since midnight UTC on January 1, 1970. It sounds simple until you have to guess the unit of a bare integer: 1735689600 is a perfectly reasonable count of seconds (landing in January 2025), but it's also a perfectly reasonable count of milliseconds if it had a few more digits — and there's no marker in the number itself that tells you which. Systems disagree by convention: JavaScript's Date.now() returns milliseconds, most Unix tooling uses seconds, and some logging systems use microseconds or even nanoseconds.
The practical rule of thumb is digit count: 10 digits is roughly seconds (covers 2001–2286), 13 digits is roughly milliseconds, 16 is microseconds. But 'roughly' is the operative word — a seconds value from the near future and a milliseconds value from the 1970s can have the same digit count for a narrow window, which is exactly the ambiguity this converter flags explicitly rather than silently picking one interpretation.
There's a second, less obvious deadline baked into Unix time: the classic 32-bit signed integer used to store it overflows on January 19, 2038 — the so-called Year 2038 problem, a spiritual successor to Y2K. Modern 64-bit systems aren't affected, but plenty of embedded systems, old database columns, and serialized formats still use a 32-bit signed int for epoch time, so a timestamp that resolves to a date past that boundary is worth a second look at what's actually storing it.
This converter tries every plausible unit interpretation in parallel, always shows both the seconds and milliseconds reading when the input is ambiguous, and renders the result in UTC, your local timezone, and relative human time ('3 days ago') side by side.
Edge cases worth knowing
- A 10-digit number that could be seconds or an oddly-short millisecond value
- Rather than guessing, this converter shows both interpretations explicitly and flags the ambiguity as an info finding — the seconds reading and the milliseconds reading of the same digits land in wildly different centuries, so context (where did this number come from?) is what actually resolves it.
- A timestamp past January 19, 2038
- Flagged as a warning: any system still storing epoch time in a signed 32-bit integer will overflow at exactly this boundary. If this timestamp is meant for long-lived storage (a certificate expiry, a scheduled event far out), verify the storage type isn't a legacy 32-bit field.
- Windows FILETIME instead of Unix time
- FILETIME counts 100-nanosecond intervals since January 1, 1601, not 1970 — a raw FILETIME value looks like an enormous number (18+ digits) compared to Unix seconds. This converter detects the FILETIME range and offsets it correctly rather than reporting a nonsense date centuries away.
Common mistakes
- Passing a milliseconds value straight into a library that expects seconds (or vice versa), landing on a date off by a factor of 1000.
- Assuming a displayed date is UTC when it was actually rendered in local time, or vice versa, when comparing timestamps across systems.
- Storing far-future expiry dates in a 32-bit signed integer column without checking for the 2038 overflow boundary.
- Confusing FILETIME's 1601 epoch with Unix time's 1970 epoch when parsing Windows-originated logs.