Timestamp Converter
epoch ⇄ dateTurn a Unix timestamp into a date and back, in seconds or milliseconds.
accepts a unix timestamp in seconds, milliseconds, microseconds, or nanoseconds — or any date your browser can parse
right now
About Timestamp Converter
Paste a Unix timestamp and read it back as a date, or paste a date and read it back as a timestamp. The unit is worked out from the size of the number — ten digits is seconds, thirteen is milliseconds, and microseconds and nanoseconds are recognised too — so there is no dropdown to get wrong.
One instant is shown every way you might need to quote it: ISO 8601 in UTC, the RFC-style UTC string, your own local time with its timezone, seconds, milliseconds, the day of the week, and how long ago or ahead it is in plain words. That last one is what usually settles the question of whether a log line is from this deployment or the last one.
The strip at the bottom shows the current time, ticking, in every format at once — handy when you need a timestamp for a fixture or a database query right now. All of it is computed by your browser from your own system clock.
Common questions
- What is a Unix timestamp?
- A count of seconds since midnight UTC on 1 January 1970, the Unix epoch. Because it is a single number in a single timezone, it is unambiguous — which is why almost every database, log format, and API uses it internally instead of a formatted date.
- Seconds or milliseconds — how do I tell?
- By length. A present-day timestamp in seconds has ten digits; in milliseconds it has thirteen. If a date comes out in 1970 you have fed seconds to something expecting milliseconds; if it lands fifty thousand years from now, the reverse. JavaScript uses milliseconds, most other languages use seconds, and that mismatch is the usual cause.
- Which timezone are the results in?
- Both. The ISO and UTC rows are in UTC, and the local row uses your computer's timezone, labelled so there is no doubt which is which. The timestamp itself carries no timezone at all — it is the same number everywhere on Earth.
- What is the year 2038 problem?
- Systems storing timestamps in a signed 32-bit integer overflow on 19 January 2038 and wrap around to 1901. Anything using 64-bit integers, which includes JavaScript numbers and modern databases, is unaffected — but old C code and some embedded systems still are.
This page does the work itself, in this tab. Nothing you paste is sent to a server. Close the tab and no copy remains.