Unix time counts seconds from a single fixed instant — midnight at the start of 1 January 1970 UTC — and it is how servers, logs, databases, and APIs quietly agree on time. This converter translates Unix timestamps into ISO 8601 and UTC date strings, and converts dates back into timestamps, detecting seconds versus milliseconds automatically.
How It Works
The engine looks at the magnitude of your number. If its absolute value is below , it is treated as seconds and multiplied by 1,000; otherwise it is treated as milliseconds — the two scales real systems actually emit (JavaScript's Date.now() is milliseconds; PHP's time() and most API created_at fields are seconds). The converted instant is then reported three ways: Unix seconds (any fractional part is floored), ISO 8601 (2026-03-09T12:00:00.000Z), and a UTC string (Mon, 09 Mar 2026 12:00:00 GMT). Enter a date instead of a number and the flow reverses.
Time Scales at a Glance
| Unit | Digits (today) | Emitted by |
| --- | --- | --- |
| Seconds | 10 | Unix date +%s, Python time.time(), most REST APIs |
| Milliseconds | 13 | JavaScript Date.now(), Java currentTimeMillis() |
| Microseconds | 16 | Python datetime, PostgreSQL timestamps |
| Nanoseconds | 19 | Go UnixNano(), kernel tracing |
Only the first two are auto-detected here. Feed a 16- or 19-digit value and it will be read as milliseconds and land absurdly far in the future — divide microseconds by 1,000 (or nanoseconds by 1,000,000) to milliseconds first. That scale ambiguity is responsible for a steady share of "date shows year 56,000" bugs in production systems.
Worked Example
An API returns created_at: 1773057600.
- Ten digits and below → seconds.
- Days since epoch: days, remainder 43,200 seconds.
- The remainder is exactly 12 hours, so the time is 12:00:00 UTC.
- Result: Monday, 9 March 2026, 12:00:00 UTC — ISO form
2026-03-09T12:00:00.000Z.
Converting back is exact: that date entered as a date returns 1773057600, because Unix time models every day as precisely 86,400 seconds.
Two Things Unix Time Quietly Ignores
Leap seconds. Civil time occasionally inserts a leap second to stay aligned with Earth's rotation; Unix time ignores them entirely, treating every day as 86,400 seconds. Systems that must agree on sub-second civil events handle the discrepancy elsewhere.
Time zones. A timestamp is an absolute instant — the same everywhere on Earth. Zones and daylight saving only enter when a human reads it, which is why this converter reports UTC and ISO forms: store the timestamp, localize at display, and an entire category of scheduling bug disappears. (The Year 2038 problem is the other famous caveat: 32-bit signed timestamps overflow at 03:14:07 UTC on 19 January 2038; 64-bit storage extends the range to roughly 292 billion years.)
Limitations
Input dates are parsed by your browser's date parser, which accepts ISO formats reliably but treats some locale formats inconsistently — prefer YYYY-MM-DD or full ISO strings. The output timestamp is whole seconds; sub-second precision entered through the date path is not preserved.
Frequently Asked Questions
Why did my timestamp convert to a date in 1970?
You almost certainly entered milliseconds into a seconds expectation — or the reverse somewhere upstream. A 13-digit millisecond value read as seconds lands tens of thousands of years out, while a seconds value read as milliseconds collapses to January 1970. Check the digit count against the table above.
Is Unix time the same in every country?
Yes — the count itself is universal and zone-free. Only the rendered calendar form changes with timezone. Two servers on opposite sides of the planet agree on 1773057600 exactly, even though one calls it Monday morning and the other Monday evening.
What is the epoch itself as a timestamp?
Zero — 1970-01-01T00:00:00Z — and negative timestamps count backwards from it for earlier dates. This converter handles negative values through the same magnitude rule.