The mistake is always seconds versus milliseconds
A Unix timestamp is a count since midnight UTC on 1 January 1970. What the count is independs entirely on what produced it, and nothing about the number says which.
- Seconds, 10 digits. PHP, Python, most REST APIs, most Unix tools.
- Milliseconds, 13 digits. JavaScript, Java, most log files.
- Microseconds, 16 digits. Postgres internals, some tracing systems.
- Nanoseconds, 19 digits. Go, InfluxDB, high-resolution tracing.
Get it wrong in one direction and you land in the year 56,000, which is obvious. Get it wrong in the other and you land in January 1970, which is not, because 1970 looks like a real date rather than an error.
That second case is the common one, and this tool goes out of its way to catch it: if the number makes no sense in the unit chosen but lands on a believable date in another, it says so and names the unit.
An epoch value has no time zone, and that matters more than it sounds
It is an instant, not a clock reading. The same number is 14:30 in London and 09:30 in New York and 18:30 in Dubai, and none of those is more correct than the others.
Nearly every converter shows one date, which is quietly its own browser's opinion. So this shows two, always: UTC, which is what the number means, and your machine's zone, named, with its offset. If you are debugging a log written on a server in another country, the UTC line matches the log.
Going the other way needs a zone, so it asks
"2026-08-17 14:30" is not a moment until you say where. It is a different instant in every zone, and the difference is exactly the sort of thing that puts a scheduled job an hour out twice a year.
There is no sensible default, so the tool asks rather than guessing, and the date is written year first because 03/04/2026 means two different days depending on which side of the Atlantic wrote it.
2038, and why it is not just a curiosity
A signed 32-bit seconds counter reaches its maximum at 03:14:07 UTC on 19 January 2038and wraps round to 1901. Anything built in the last decade uses 64 bits and is unaffected for the next 292 billion years.
What is affected is the long tail: embedded controllers, older database columns typed as a 32-bit integer, some binary file formats, and anything with a mortgage or a lease end date in it. A thirty-year term signed today already runs past the limit, which is why the warning is here rather than filed under trivia.
Leap seconds, briefly
Unix time assumes every day is exactly 86,400 seconds. It is not: leap seconds are occasionally added to keep clocks in step with the earth's rotation, and Unix time handles that by repeating a second rather than counting it.
So the difference between two timestamps spanning a leap second is very slightly wrong. For anything short of scientific timing this does not matter, but it is worth knowing that "seconds since 1970" is not literally true.
Everything runs on your own machine. Nothing is uploaded and nothing is stored.
Common questions
My timestamp converts to the year 56,000. What went wrong?
A milliseconds value was read as seconds. Multiplying by a thousand pushes the date about fifty thousand years into the future, which is unmistakable once you know to look for it. Set the unit to milliseconds and it will land in this century.
My timestamp converts to January 1970.
The opposite mistake: a seconds value read as milliseconds, so the date lands a couple of weeks after the epoch. This one is more common and much easier to miss, because 1970 looks like a plausible date rather than an obvious error. The tool checks whether another unit would put the same number somewhere sensible and tells you which.
How do I know whether a number is in seconds or milliseconds?
Count the digits. For any date in the last few decades, seconds is 10 digits, milliseconds 13, microseconds 16 and nanoseconds 19. PHP, Python and most REST APIs give seconds. JavaScript, Java and most log files give milliseconds. Databases and tracing systems are where the longer ones turn up.
Which time zone is a Unix timestamp in?
None. It is a count of time since a fixed instant, so it identifies a moment rather than a clock reading. The same number is 14:30 in London and 09:30 in New York, and both are correct. That is why this shows UTC and your own zone side by side and names the zone, rather than showing one date and letting you assume.
What is the 2038 problem?
A signed 32-bit integer counting seconds runs out at 03:14:07 UTC on 19 January 2038 and wraps round to 1901. Modern systems use 64 bits and are fine for about 292 billion years, but plenty of embedded hardware, older database columns and file formats still use 32. The tool warns when a value is past that point.
Can a timestamp be negative?
Yes, and it means a date before 1970. It converts correctly here. Be careful passing one on: a lot of software treats a negative epoch as an error, or clamps it to zero, without saying so.
Does Unix time count leap seconds?
No, and this trips people up. Unix time pretends every day is exactly 86,400 seconds, so when a leap second is inserted the count repeats a second rather than advancing. It means the difference between two timestamps is not quite the true elapsed time across a leap second. For everything short of scientific timing it does not matter.
Why does it want the year first when I type a date?
Because 03/04/2026 is 3 April in Britain and 4 March in the United States, and there is no way to tell which you meant. Year, month, day removes the ambiguity, and it is the ISO 8601 order that most systems expect anyway.