Online Tool Store
UNIX Timestamp Converter
Convert Unix timestamps in seconds, milliseconds, microseconds or nanoseconds to dates and back, with UTC, local time, ISO week and 2038 warnings.
🔒 This tool runs entirely in your browser. Your files are never uploaded to a server.
—
How to use it
- Paste a timestamp. The unit is guessed from its size and the guess is shown.
- Read UTC and your local time together, with the offset stated.
- Override the unit if the guess is wrong for your data.
- Switch direction to turn a date and time into a timestamp instead.
The unit is the whole problem
A Unix timestamp is a bare number, and nothing in it records whether it counts seconds, milliseconds or something finer. The same digits mean wildly different dates:
1700000000 as seconds → 2023-11-14
1700000000 as milliseconds → 1970-01-20
today: seconds have 10 digits, milliseconds 13,
microseconds 16, nanoseconds 19
Counting digits is a good heuristic and a bad guarantee — it works because we happen to live in a stretch of time where the digit counts differ, and it fails on any old date. So the detection is shown rather than applied silently, and you can override it.
2038, to the second
2147483647 → 2038-01-19T03:14:07Z largest signed 32-bit int
-2147483648 → 1901-12-13T20:45:52Z where it wraps to
Systems storing Unix time in a signed 32-bit integer stop working at that instant, and the failure is not a graceful one: the value wraps to 1901, so timers fire immediately, certificates look expired, and sorting goes backwards. This is not a museum problem — it lives on in embedded firmware, older binary formats and database columns that were defined as INT decades ago. The tool warns when a value is over that line, and also when it is within a few years of it.
Unix time does not count leap seconds
This is the detail that surprises people who assume a timestamp is a count of elapsed seconds. It is not. A Unix day is defined as exactly 86,400 seconds, and UTC occasionally has a day with 86,401 because a leap second was inserted to keep clocks aligned with the Earth's rotation. Unix time simply ignores those:
2016-12-31T00:00:00Z → 2017-01-01T00:00:00Z
real elapsed time 86,401 SI seconds (a leap second was added)
Unix difference 86,400
Twenty-seven leap seconds have been inserted since 1972, and none of them appear in Unix time. If you need a genuine count of elapsed seconds you need TAI, not Unix time. The practical upshot for most software is small — but if you are measuring durations across a leap second, or comparing against a GPS clock, it is not nothing. The international decision in 2022 to retire leap seconds by 2035 will eventually make this a historical curiosity.
Zones, and what a timestamp does not contain
A timestamp is an instant. It has no time zone, no offset and no notion of daylight saving — those exist only when you render it for a human. That is why the same timestamp shows two different wall-clock times here, and why the date-to-timestamp direction has to ask whether you meant local or UTC: a date and time without a zone is genuinely ambiguous, and quietly guessing is how off-by-an-hour bugs get shipped.
FAQ
Is my timestamp in seconds or milliseconds?
Count the digits: today a seconds value has 10 and a milliseconds value has 13. But that is a guess, not a fact — 1700000000 is November 2023 read as seconds and January 1970 read as milliseconds, and the number itself carries no unit. The tool shows which reading it chose so you can override it.
What is the 2038 problem?
The largest signed 32-bit integer is 2,147,483,647, which as a Unix timestamp is 2038-01-19T03:14:07Z. Any system still storing time in a signed 32-bit field will wrap round from there to 1901-12-13T20:45:52Z. It is the same shape of problem as Y2K and it is still present in embedded devices, old file formats and database columns nobody has looked at.
Does Unix time count leap seconds?
No, and this trips people up. A Unix day is defined as exactly 86,400 seconds, so leap seconds are simply skipped — the timestamps either side of the one inserted at the end of 2016 are 86,400 apart, as if it never happened. That means Unix time is not a true count of elapsed seconds since 1970; it is a count of days times 86,400 plus the time of day.
Can a timestamp be negative?
Yes. Negative values are simply times before 1970 — −86400 is 1969-12-31. The arithmetic is fine; the risk is software that assumes non-negative and does something odd with it.
Why do I get a different answer to my database?
Almost always a time-zone reading rather than a wrong timestamp. A Unix timestamp is an instant with no zone at all; what varies is which zone you render it in. The tool shows UTC and your local time side by side, with the offset spelled out.
What is the largest date it will accept?
A JavaScript date spans exactly ±100,000,000 days either side of 1970, which is −271821-04-20 to +275760-09-13. One millisecond further and it becomes an invalid date rather than a wrong one, and the tool says so instead of showing something misleading.
How we compare
| Feature | Online Tool Store | Other timestamp sites | A one-line shell command |
|---|---|---|---|
| Detects the unit and says which it chose | ✓ | Often assumes seconds | ✗ |
| Micro and nanosecond input | ✓ | Rarely | With arithmetic |
| Warns about the 2038 boundary | ✓ | ✗ | ✗ |
| ISO week, day of year and relative time | ✓ | Sometimes | With more flags |
| Nothing sent to a server | ✓ | Varies | ✓ |
| Scriptable over a whole log file | ✗ | ✗ | ✓ |
| Any named time zone, not just UTC and yours | ✗ | Sometimes | ✓ |
For the usual case — one timestamp out of a log, and a nagging doubt about the unit — this answers it and flags the
traps. For converting a whole file, or rendering into a specific named zone, date
on the command line is the better instrument.