Unix timestamp converter
Paste an epoch value on the left to read it as a date, or pick a date on the right to get the epoch value back. The unit — seconds, milliseconds or microseconds — is worked out from the size of the number, and the page tells you which one it assumed.
Current Unix time: …
| Local time | — |
|---|---|
| UTC | — |
| ISO 8601 | — |
| RFC 2822 | — |
| Day of the week | — |
| Relative | — |
| Seconds | — |
|---|---|
| Milliseconds | — |
Every conversion happens in this tab. No timestamp, date or timezone is uploaded or stored, and the page keeps working with the network switched off.
How the conversion works
A Unix timestamp counts the elapsed time since midnight UTC on 1 January 1970. Nothing else is encoded in it — no timezone, no calendar, no daylight saving. That is the whole appeal: one integer means the same instant everywhere, and turning it into a human date is a job for the display layer, not the storage layer.
The unit is where most confusion starts, because the number carries no label. This page decides by magnitude: fewer than eleven digits is treated as seconds, up to fourteen as milliseconds, beyond that as microseconds. That rule holds for any date you are realistically handling — a ten-digit value would have to be in the 1970s to be milliseconds, and a thirteen-digit value would be somewhere past the year 5000 to be seconds. The line under the input always states which unit it used, and the select overrides it when you know better.
Converting the other way, the date picker reads in your device's timezone, because that is what a datetime-local field means. Pick 14:00 in London and 14:00 in Tokyo on two machines and you get two different timestamps, correctly — they are two different instants. The timezone the page is using is named under the picker so there is no guessing.
Values before 1970 are negative, and they work here: -2208988800 is 1 January 1900. At the other end, a date can only stretch about 8.64 × 10^15 milliseconds either side of the epoch, which runs out in the year 275760. Feed the page something past that and it says so in plain words rather than printing "Invalid Date" and leaving you to work out why.
Questions people ask
Why does the Unix epoch start in 1970?
It was a convenience that stuck. Early Unix at Bell Labs counted sixtieths of a second in a 32-bit integer, which wrapped after about two and a half years, so the epoch had to be re-set constantly. Moving to whole seconds in the early 1970s gave a range of roughly 136 years, and 1 January 1970 was simply a tidy recent boundary to start from. There was no committee and no deep reasoning — but once file timestamps, C libraries and eventually every network protocol were built on it, the date became permanent by accident.
Why is my converted date wrong by a factor of a thousand?
Because something in the chain disagreed about the unit. JavaScript's Date.now(), Java's System.currentTimeMillis() and most JSON APIs hand back milliseconds. C, Python's time.time(), PostgreSQL's extract(epoch …), Go's Unix() and almost every log format use seconds. Passing a seconds value to a milliseconds parser lands you in January 1970; the reverse throws you tens of thousands of years into the future. If a date looks absurd, count the digits first — ten means seconds, thirteen means milliseconds.
What actually happens in 2038?
At 03:14:07 UTC on 19 January 2038 a signed 32-bit seconds counter overflows and flips to December 1901. Anything still storing time in a 32-bit time_t — old embedded firmware, some file formats, a few database columns typed as INT — will misbehave then. Modern 64-bit systems are unaffected, and have been for years. The realistic risk is not the operating system but the schema: a timestamp column declared as a 32-bit integer in 2012 will still be a 32-bit integer in 2038 unless somebody widens it.
Do Unix timestamps include leap seconds?
No, and that is a deliberate simplification. Unix time pretends every day has exactly 86,400 seconds, so when a leap second is inserted the counter either repeats a value or is smeared across the surrounding hours, depending on the platform. This means a Unix timestamp is not a true count of elapsed physical seconds since 1970 — it is currently short by 27 of them. For scheduling, logging and expiry that difference never matters. For anything measuring real intervals across years, use a monotonic clock instead.
Why does the same timestamp show a different time for my colleague?
Because the timestamp is the same and the rendering is not. The number is a fixed instant in UTC; what you see depends on the timezone of the machine displaying it and on whether daylight saving was in effect at that particular date — not today. That last part catches people out: converting a July timestamp in January still has to apply July's offset. Both the local line and the UTC line are shown above so you can see the gap. When two systems must agree, exchange the timestamp or the ISO 8601 string with its offset, never the local rendering.