Unix timestamp converter

Unix time (also called epoch time or POSIX time) counts the seconds that have passed since the Unix epoch, 1970-01-01T00:00:00Z. It is one number with no time zone, so it is easy to store, sort, compare and subtract: two timestamps an hour apart always differ by 3600.

POSIX defines the count so that every day has exactly 86,400 seconds. Leap seconds are not counted, which keeps date math simple: the timestamp of midnight UTC is always a multiple of 86,400. Times before 1970 are negative numbers, so -86400 is 1969-12-31T00:00:00Z.

Different systems count in different units. The number of digits tells you which one you have: for dates between 2001 and 2286, seconds have 10 digits. The converter uses the size of the number to decide, and you can force a unit with the s / ms / µs / ns switch.

The auto-detect rule: below 10¹¹ it is seconds (that covers dates up to the year 5138), below 10¹⁴ milliseconds, below 10¹⁷ microseconds, and nanoseconds above that. Nanosecond timestamps are larger than JavaScript can hold exactly in a Number (2⁵³ − 1), so this tool does the math with BigInt and keeps all nine fractional digits.

Pick a language under the result to get these snippets filled in with your timestamp and time zone. The short versions:

The most common bug is a unit mix-up: JavaScript's Date takes milliseconds, so new Date(1735689600) gives a date in January 1970. Multiply seconds by 1000 first. The reverse mistake, passing milliseconds to a function that expects seconds, lands tens of thousands of years in the future.

Spreadsheets. In Google Sheets, =EPOCHTODATE(A1) converts seconds to a UTC date; pass 2 as the second argument for milliseconds or 3 for microseconds. Excel has no built-in function, but its dates are day counts where 1970-01-01 is day 25569, so =A1/86400+25569 gives the UTC date (format the cell as a date). The converter shows that serial number for you.

One instant, written in the formats you are most likely to need:

Time zones use IANA names like Europe/Berlin or America/New_York, not fixed offsets. A name carries the daylight saving rules, so the offset is right for each date: New York is UTC−5 in January and UTC−4 in July. When you type a date without an offset, the converter reads it as wall-clock time in the zone you picked, or in the zone you name at the end, as in 2025-01-01 09:30 Europe/Berlin. Numeric dates like 05/01/2025 are read month first (US order) unless the first number is above 12; dotted dates like 05.01.2025 are read day first.

DST edge cases. On the night clocks jump forward, times like 02:30 in New York do not exist; the converter moves them forward by the length of the jump (02:30 becomes 03:30 EDT) and says so. When clocks go back, 01:30 happens twice; it takes the first one and tells you. This matches the "compatible" rule of JavaScript's Temporal API.

Older C code stores time_t as a signed 32-bit integer. Its largest value, 2147483647, is 2038-01-19T03:14:07Z; one second later it overflows to -2147483648, which reads as 1901-12-13T20:45:52Z. 64-bit time_t is standard on current Linux, macOS and Windows builds, but 32-bit fields in databases, file formats and embedded devices can still break. The result table says whether a timestamp fits in 32 bits.

JavaScript dates cover ±8.64 × 10¹⁵ milliseconds around the epoch, from April 271,821 BC to September 275,760 AD, which is the range this tool accepts. Years past 9999 are written in the extended ISO form, such as +010000-01-01T00:00:00Z.

Timestamps also show up inside other formats. JWT claims exp, iat and nbf are seconds, which the JWT decoder converts for you. UUID v7 and ULID start with a millisecond timestamp (see the UUID generator). To schedule jobs rather than convert times, use the cron expression generator. Storing timestamps in a database? Browse database tools on DevHunt.