Unix timestamp converter
Turn epoch seconds into a readable date, or a date back into epoch seconds. It tells you which unit it read and which time zone it rendered into.
Date and time
20260807
17:50:38
Friday, 7 August 2026 in UTC (GMT), read as seconds.
Seconds since 1 January 1970 UTC. Negative numbers are dates before it.
Read as seconds, from how many digits it has.
1786125038
Read as a wall-clock time in UTC.
Counted in UTC (GMT), not counting today.
Change either and every figure above updates. Most date tools pick a zone and a counting rule silently, which is why two sites can answer the same question with different numbers.
How epoch time works
A Unix timestamp is one number: the count of seconds since midnight UTC on 1 January 1970. It carries no time zone and no formatting, which is the whole point. Two machines on opposite sides of the world mean precisely the same instant by the same number, and no argument about date formats can come between them.
The cost of that simplicity is that a timestamp is unreadable until you render it, and rendering requires a time zone. The same number is a Tuesday evening in London and a Wednesday morning in Tokyo. That is not a discrepancy; it is what the number means. This page names the zone it used under every answer, and you can change it.
Seconds, milliseconds, and the mistake everyone makes
Different systems count in different units. Unix tools and most databases use seconds. JavaScript, Java and many APIs use milliseconds. Some high-resolution sources use microseconds or nanoseconds. The numbers look alike, and pasting one where another is expected gives an answer that is wrong by a factor of a thousand rather than one that looks obviously broken.
The reliable check is the digit count. In the current era, a timestamp in seconds has ten digits and the same instant in milliseconds has thirteen. This converter reads the magnitude, says which unit it assumed, and lets you override it.
Two things that are quietly not true
Unix time is often described as the number of seconds since 1970. It is very nearly that, and the gap is worth knowing about. Unix time is defined as though every day contains exactly 86,400 seconds, so it does not count leap seconds. Around 27 real seconds have been inserted into UTC since 1972 and none of them appear in a Unix timestamp. For scheduling, logging and almost everything else this is irrelevant. For precise interval measurement it is not.
The other is the year 2038. Any system still holding a timestamp in a signed 32-bit integer stops at 2147483647, which is 03:14:07 UTC on 19 January 2038, and the next second reads as December 1901. Modern systems use 64-bit values. This page uses your browser's own arithmetic, so it handles dates hundreds of thousands of years out.
Questions
What is a Unix timestamp?
A Unix timestamp is the number of seconds that have elapsed since 1 January 1970 at 00:00:00 UTC, a moment usually called the epoch. It is a single number with no time zone attached, which is exactly why it is used: two systems anywhere in the world mean the same instant by it. Negative values are dates before 1970.
Is my number in seconds or milliseconds?
Count the digits. A timestamp in seconds for any date in the current era has 10 digits; the same instant in milliseconds has 13. This converter reads the magnitude and tells you which unit it assumed, and you can override it. Getting this wrong is the most common mistake with epoch time, and it produces an answer that is out by a factor of 1,000 rather than one that looks obviously broken.
Does a Unix timestamp include leap seconds?
No, and this is a genuine subtlety rather than a rounding detail. Unix time is defined as if every day has exactly 86,400 seconds, so it quietly ignores leap seconds. That means a Unix timestamp is not a true count of elapsed SI seconds since 1970; it is a count of days and seconds-within-day. For almost all purposes this does not matter, and for precise scientific timing it does.
What is the year 2038 problem?
Systems that store a Unix timestamp in a signed 32-bit integer run out of room at 03:14:07 UTC on 19 January 2038, which is 2147483647 seconds. One second later the value overflows and reads as December 1901. Modern systems use 64-bit values and are unaffected for longer than the sun will last. This page uses your browser's own numbers, which are 64-bit floating point, so it handles dates far beyond 2038.
Why does the same timestamp show a different clock time for me than for a colleague?
Because the timestamp is the same instant but you are in different places. The number carries no time zone, so it has to be rendered into one to be read. This page shows you which zone it used under the answer, and you can change it.
What is the largest timestamp this can handle?
Dates run to roughly 273,790 years either side of 1970, which is the limit of what a date can represent in a browser. Beyond that the converter says so rather than showing a wrong figure or an error.