Unix Timestamp Converter

Paste a Unix timestamp and the calculator renders it as a readable UTC date; switch the direction and it turns any calendar date and time back into epoch seconds and milliseconds. The timestamp field is filled with the current epoch second when the page loads, so the first result is simply now; the value does not tick onward. Four outputs update together: a spelled-out UTC date and time, the same instant in ISO 8601, and the raw counts in seconds and in milliseconds. The unit selector defaults to auto-detect, which reads any number with an absolute value of a trillion or more as milliseconds, the everyday rule that separates ten-digit second counts from thirteen-digit millisecond counts.

How the conversion works

Unix time is a single integer: the count of non-leap seconds since 00:00:00 UTC on 1 January 1970, a moment known as the epoch. Because every day is treated as exactly 86,400 seconds, the conversion from a calendar date is plain multiplication:

seconds = days × 86,400 + h × 3,600 + m × 60 + s

where days is the count of whole days between the epoch and the date in question. Going the other way, dividing the timestamp by 86,400 gives the day, and the remainder is the time of day. The fiddly part is turning a day number into a month and a year, which this tool delegates to the JavaScript Date object working strictly through its UTC accessors, so no time zone or daylight-saving rule ever touches the arithmetic. Milliseconds are the same count multiplied by a thousand. The auto-detect threshold sits at a trillion because the two scales barely overlap in practice: a trillion seconds lies more than 31,000 years in the future, while a trillion milliseconds was the morning of 9 September 2001, so any present-day value sorts itself unambiguously onto one side or the other.

A worked example in both directions

Take 13 August 2026 at 09:15:00 UTC. From 1970 to 2026 is 56 whole years, of which 14 were leap years, giving 56 × 365 + 14 = 20,454 days to 1 January 2026. January through July of 2026 add 31 + 28 + 31 + 30 + 31 + 30 + 31 = 212 days, and 12 more full days land on 13 August, for 20,678 days in total. Multiplying by 86,400 gives 1,786,579,200 seconds, and the clock time adds 9 × 3,600 + 15 × 60 = 33,300 more, so the timestamp is 1,786,612,500.

The reverse direction is a division. The timestamp 1,000,000,000 splits into 11,574 whole days with 6,400 seconds left over; the remainder is 1 hour, 46 minutes and 40 seconds, and day 11,574 after the epoch is 9 September 2001. That instant, 01:46:40 UTC on Sunday 9 September 2001, produced the first ten-digit timestamp — the press coined the name billennium for it — and every second since has needed ten digits, which is what makes the digit-count heuristic for telling seconds from milliseconds so dependable.

Why the count starts in 1970

Unix time is slightly younger than Unix, and the epoch wandered before it settled. As the history is told in Wikipedia's account of Unix time, the earliest versions of the system kept time as a 32-bit integer ticking 60 times a second, the rate of the hardware clock on the machines Unix first ran on, and the first edition of the programmer's manual, dated November 1971, described the system time as the count of sixtieths of a second since 00:00:00 on 1 January 1971. Sixty ticks a second is a punishing rate for a 32-bit register, and a manual page revised in March 1972 shows the epoch already reset to the start of 1972, alongside a deadpan admission: "The time is stored in 32 bits. This guarantees a crisis every 2.26 years." The durable fix changed the unit instead of the start date. Counting whole seconds pushed the overflow horizon out by decades, and 1 January 1970 became the fixed origin. Dennis Ritchie explained the choice to Wired in 2001, as the billionth second approached: the team had grown tired of moving time's starting point as counters filled, wanted an origin with room to run, and settled on 1970 as being as good a date as any. The POSIX standard later formalised the definition as arithmetic over the fields of a UTC date, which is the definition this calculator implements.

Every day is exactly 86,400 seconds

Real civil timekeeping is less tidy than Unix time pretends. UTC occasionally inserts a leap second to stay aligned with the Earth's rotation, but Unix time ignores this entirely: every day contains exactly 86,400 seconds, and a leap second simply shares its timestamp with the second beside it. During a positive leap second at the end of a day — UTC has inserted 27 of them between 1972 and the end of 2016 — the Unix count runs on into the new day and then jumps back by one, handing the same number out twice. The POSIX committee, as the same Wikipedia history records, weighed a strictly linear count of elapsed seconds against a representation that mirrors civil time and accepted the leap-second wrinkle, persuaded by the argument that conversions between timestamps and dates should stay simple. The standard is open about this: it describes the value as approximating the seconds elapsed since the epoch, and declares the relationship between the count and the actual time of day unspecified. The practical consequence is that subtracting one timestamp from another yields an elapsed time that silently omits any leap seconds between them, a discrepancy far too small to matter for logs and expiry dates but real enough that precision timekeeping uses other scales.

The year 2038 boundary

A signed 32-bit integer tops out at 2,147,483,647, and a system storing Unix seconds in one runs out of numbers at 03:14:07 UTC on Tuesday 19 January 2038. One second later the sign bit flips, the value becomes −2,147,483,648, and the clock reads 20:45:52 UTC on 13 December 1901. The same limit bounds the past: 13 December 1901 is also the earliest instant a 32-bit timestamp can name. The Year 2038 problem surfaced long before its deadline. In May 2006 the AOLserver web server began crashing because a configuration shortcut expressed no timeout as a hardcoded one billion seconds in the future, and one billion seconds before the 2038 cutoff fell at 01:27:28 UTC on 13 May 2006 — from that morning on, every such calculation overflowed. On 1 January 2022, Microsoft Exchange's malware scanning broke when update version numbers, packed into a signed 32-bit field as timestamp-like values, exceeded 2,147,483,647. The remedy is a 64-bit count, which extends the range to roughly 292 billion years. NetBSD 6.0 moved to 64-bit time on all architectures in October 2012, OpenBSD 5.5 followed in May 2014, the Linux kernel gained 64-bit time support for 32-bit hardware in version 5.6, released in March 2020, and glibc 2.34 offered it to 32-bit userland in August 2021 as an opt-in build setting rather than a default. The stragglers are embedded devices already in the field, which is why the deadline still gets attention.

Seconds, milliseconds and the factor-of-a-thousand trap

The commonest timestamp bug is not the distant 2038 rollover but a plain unit mix-up. The Unix convention counts seconds; JavaScript, Java and many logging pipelines count milliseconds. Feed a seconds value into an API expecting milliseconds and the result lands in January 1970 — 1,786,612,500 read as milliseconds is only about 20.7 days after the epoch. Make the opposite mistake and a present-day millisecond count read as seconds lands over 56,000 years in the future. Either mistake is obvious the moment the value is rendered as a date. The digit heuristic holds until seconds reach eleven digits in the year 2286, so for the foreseeable future ten digits mean seconds and thirteen mean milliseconds, and auto-detect leans on exactly that gap.

Assumptions and range

Everything here is computed in UTC; no local time zone, daylight-saving rule or locale setting enters at any point, which is why the output can differ from your wall clock by your UTC offset. The representable span is that of the JavaScript Date object: 100,000,000 days either side of the epoch, or 8,640,000,000,000,000 milliseconds, roughly 273,000 years each way, and values beyond it return an error rather than a wrapped date. Negative timestamps are valid and reach back before 1970. Auto-detect switches to milliseconds at an absolute value of one trillion; timestamps from the era before 9 September 2001 in milliseconds, or far-future dates in seconds, can fall on the wrong side of that line, and the unit selector overrides the guess. Fractional input is rounded down to a whole second or millisecond and the result is flagged. The calendar is proleptic Gregorian throughout, so dates before the 1582 calendar reform are labelled by projection rather than as contemporaries wrote them.

Frequently asked questions

What is a Unix timestamp?

A Unix timestamp is a count of seconds since 00:00:00 UTC on 1 January 1970, a moment called the Unix epoch. Every day is treated as exactly 86,400 seconds, leap seconds are ignored, and the same number means the same instant everywhere on Earth. Timestamps near the present are ten digits long in seconds and thirteen digits in milliseconds.

Why does Unix time start on 1 January 1970?

The earliest Unix systems counted sixtieths of a second, and the 1971 manual measured that count from 1 January 1971. At sixty ticks a second a 32-bit counter overflows in about 2.26 years, so the epoch kept moving, and a 1972 revision of the manual restarted it at 1972. Switching the unit to whole seconds removed the short-term overflow, and Dennis Ritchie told Wired in 2001 that the team simply wanted an origin that would not overflow for a while, with 1970 seeming as good as any.

What is the Year 2038 problem?

Systems that store Unix time in a signed 32-bit integer run out of numbers at 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. The fix is a 64-bit count, which modern operating systems have been adopting since the 2010s and which extends the range by around 292 billion years.

Is a Unix timestamp in seconds or milliseconds?

The Unix convention is seconds, but many environments, JavaScript among them, count milliseconds. A present-day value has ten digits in seconds and thirteen in milliseconds. This converter auto-detects by treating any absolute value of a trillion or more as milliseconds, and a manual unit override is available for anything ambiguous.

Does Unix time count leap seconds?

No. Unix time treats every day as exactly 86,400 seconds. When UTC inserts a positive leap second, the Unix count runs on into the new day and then jumps back by one, so a leap second shares its timestamp with the second next to it. Two timestamps subtracted therefore give elapsed time that omits any leap seconds between them.

What time zone is a Unix timestamp in?

None, in effect. A timestamp identifies an instant, not a wall-clock reading, so it is the same number in Tokyo and in Toronto. Converting it to a date requires choosing a zone, and this calculator always uses UTC, which is why the result may differ from your local wall clock by your UTC offset.