Unix Timestamp Converter

How to use the Unix timestamp converter

1. To read a timestamp, paste it into the first tab. The tool works out whether it is in seconds, milliseconds, microseconds or nanoseconds, and shows the date in UTC, in your local time and as ISO 8601.
2. To make a timestamp, switch to Date → timestamp, pick a date and time, and say whether it is UTC or your local time zone.
3. The box at the top shows the current Unix time, ticking every second, with buttons to copy it in seconds or milliseconds.

Every row in the results table has its own Copy button, which is useful for pasting into code, a database query or a log search.

What a Unix timestamp is

A Unix timestamp counts the seconds that have passed since 00:00:00 UTC on 1 January 1970, a moment called the Unix epoch. Because it is a single number that is the same everywhere in the world, programmers use it to store and compare moments in time without worrying about time zones, calendars or daylight saving. Converting it to a readable date is only needed when a person has to look at it.

days since 1970-01-01 = timestamp ÷ 86,400 the time of day is the remainder, as hours, minutes and seconds

Unix time ignores leap seconds: every day is exactly 86,400 seconds, so the number is a clean count that is easy to do arithmetic on. Adding 86,400 always moves forward by one UTC day, and subtracting two timestamps always gives an elapsed time in seconds.

Seconds, milliseconds and beyond

The converter picks the unit from the size of the number: below 10¹¹ it is read as seconds (which covers dates until the year 5138), below 10¹⁴ as milliseconds, below 10¹⁷ as microseconds, and larger values as nanoseconds. A 13-digit number pasted by mistake into a seconds field would point to the year 55000, which is the usual sign of a milliseconds mix-up.

Worked examples

To check one by hand: 1,735,689,600 ÷ 86,400 = 20,089 days after 1 January 1970, and 20,089 days is exactly 55 years (20,089 = 55 × 365 + 14 leap days), which lands on 1 January 2025 with no time left over.

The year 2038 problem

Older systems store Unix time in a signed 32-bit integer, which runs out at 03:14:07 UTC on 19 January 2038. One second later the value wraps to a large negative number, which software reads as December 1901. Modern systems use 64-bit integers, which will not overflow for about 292 billion years, but embedded devices, old databases and file formats with 32-bit fields still need checking. If you maintain such a system, test it with the timestamp 2147483648 using this converter to see what a correct reading should be.

Using timestamps in code

The most common bug is mixing units. JavaScript counts in milliseconds, so passing a seconds timestamp straight to new Date() gives a date in January 1970. Multiply by 1000 first. The reverse mistake, treating a millisecond value as seconds, gives a date tens of thousands of years in the future.

Accuracy and limits

Conversions are exact to the millisecond. Local time uses the time zone setting of your device. The tool shows dates between the years 1 and 9999 that a browser can represent; values beyond that show an error. Because Unix time ignores leap seconds, the real elapsed time between two timestamps that span a leap second is one second longer than the difference suggests.

Frequently asked questions