Unix Timestamp Converter

How to convert a Unix timestamp

A Unix timestamp (also called epoch time or POSIX time) is the number of seconds since the Unix epoch, midnight UTC at the start of 1 January 1970 (1970-01-01T00:00:00Z). It is the same number everywhere on Earth at the same moment, which is why logs, databases and APIs store time this way. Only when you display it do you need a time zone.

1. Paste the timestamp. A 10-digit number is read as seconds, 13 digits as milliseconds (JavaScript’s Date.now()), 16 as microseconds and 19 as nanoseconds. If the guess is wrong, pick the unit yourself.
2. Choose a time zone to see the local time there. Your own local time appears too.
3. To go the other way, switch to “Date → timestamp”, enter a date, a time with seconds and the zone the time is in. “Now” fills in the current moment.

The result gives the date in UTC, an ISO 8601 string for code and data files, an RFC 2822 string as used in email headers, and the value in all four units. For clock times between cities, the time zone converter is simpler; for the span between two dates, use the days between dates calculator.

The formula

POSIX defines the timestamp by counting every day as exactly 86,400 seconds. Split the timestamp into whole days and the seconds left over:

t

the timestamp in seconds (divide milliseconds by 1,000 first)

days

whole days after 1 January 1970, counted on the Gregorian calendar; negative before it

The date is found by counting that many days from 1 January 1970, and the seconds of the day give the UTC clock time. A local time is UTC plus the zone’s offset on that date; to go back, subtract the offset first.

Leap seconds. Unix time ignores them. Because every day is 86,400 seconds by definition, a leap second has no timestamp of its own, and the count differs from the true number of elapsed SI seconds since 1970 by the leap seconds added since then. The POSIX standard states that the relationship between its count and the actual UTC time is unspecified.

Worked example

What date is the timestamp 1,800,000,000?

1. 1,800,000,000 ÷ 86,400 = 20,833 whole days, with 28,800 seconds left over (20,833 × 86,400 = 1,799,971,200).
2. 20,833 days after 1 January 1970 is Friday, 15 January 2027.
3. 28,800 seconds is 8 hours, so the moment is 2027-01-15T08:00:00Z.
4. New York is on standard time in January, UTC−05:00, so it is 3:00:00 a.m. there.

The same moment in milliseconds is 1,800,000,000,000 and in RFC 2822 form “Fri, 15 Jan 2027 08:00:00 +0000”.

In reverse, the calculator starts on 18 January 2038, 22:14:07 in New York. Adding the 5-hour offset gives 03:14:07 UTC on 19 January 2038, which is timestamp 2,147,483,647, or 2³¹ − 1: the last second a signed 32-bit counter can hold.

The year 2038 problem and other pitfalls

• 2038. Systems that store the timestamp in a signed 32-bit integer can count up to 2,147,483,647, which is 03:14:07 UTC on 19 January 2038. One second later the value wraps to −2,147,483,648, which reads as 20:45:52 UTC on 13 December 1901. 64-bit timestamps push the limit billions of years away; the result says whether a time fits in 32 bits.
• Seconds or milliseconds? The most common mistake is a factor of 1,000: JavaScript and Java use milliseconds, most Unix tools and databases seconds. A millisecond value read as seconds lands tens of thousands of years in the future (outside this converter’s range); a second value read as milliseconds lands in January 1970.
• Negative timestamps are valid and count back from 1970: −1 is 23:59:59 UTC on 31 December 1969.
• Local times are ambiguous twice a year. When clocks go back, a local time happens twice; when they spring forward, an hour is skipped. The reverse conversion uses the first occurrence and moves a skipped time forward, and says so.
• Old dates. Before time zones were standardised, around 1900, zones used local mean time, with offsets in odd minutes and seconds. ISO strings here show the offset to the minute.