Unix Timestamp Converter

What a Unix timestamp is

A Unix timestamp (epoch / POSIX time) counts the seconds since 1 January 1970 00:00:00 UTC, ignoring leap seconds. Because it is a single number in UTC, it stores an exact instant independent of timezone — which is why databases, logs and APIs use it. For example, 1700000000 is Tue, 14 Nov 2023 22:13:20 GMT (ISO 8601: 2023-11-14T22:13:20.000Z).

Seconds vs. milliseconds

Classic Unix time is in seconds (a current value is 10 digits). JavaScript and many platforms use milliseconds (13 digits). If you paste a 13-digit value with the unit set to “Auto-detect”, this tool treats it as milliseconds. Common intervals in seconds:

The Year 2038 problem

Software that stores the timestamp in a signed 32-bit integer can only count up to 2,147,483,647 seconds — reached at 03:14:07 UTC on 19 January 2038. Past that the value overflows to a negative number. The fix is to store time in 64-bit integers, which all modern systems do.

Where the 1970 epoch came from

The familiar 1970 starting point was not the first one. The earliest edition of the Unix Programmer's Manual, written at Bell Labs in November 1971, defined system time as the number of sixtieths of a second elapsed since 00:00:00 on 1 January 1971. Counting in 1/60-second ticks matched the 60 Hz line frequency the early PDP-11 hardware used to drive its clock, but a 32-bit counter advancing 60 times a second exhausts its range in only about 2.26 years — a later manual bluntly noted this "guarantees a crisis every 2.26 years."

The fix, settled by the 1972–1973 manuals, was twofold: count whole seconds instead of ticks, and move the zero point to the round date of 1 January 1970 UTC. Switching from sixtieths to seconds multiplied the usable range sixty-fold at a stroke, and the engineers — Ken Thompson, Dennis Ritchie and colleagues — picked 1970 simply because it was a convenient, tidy number to work from. That arbitrary, pragmatic choice has since become one of the most quietly load-bearing constants in computing: every modern operating system, database and programming language still counts from that exact instant.

Leap seconds, and why every Unix day is exactly 86,400 seconds

The POSIX standard defines Unix time so that every day contains exactly 86,400 seconds (60 × 60 × 24). That seems obvious until you remember that civil time is UTC, and UTC occasionally inserts a leap second to keep clocks aligned with the Earth's slightly irregular rotation. On a day with a positive leap second, UTC genuinely runs for 86,401 seconds — but Unix time is contractually forbidden from admitting it, so it simply does not count the extra second.

The result is a small but real ambiguity. The boundary value 1483228800, for instance, can mean either the leap second 2016-12-31 23:59:60 UTC or the ordinary second one tick later, 2017-01-01 00:00:00 UTC — two different real-world instants sharing one timestamp, because the same Unix value is used for two consecutive seconds so the next midnight still lands on a clean multiple of 86,400. The practical fallout: a stored Unix timestamp cannot unambiguously represent a leap second, and the difference between two timestamps that straddle one is off by the number of leap seconds in between. For most software this is invisible; high-precision systems use TAI or "smear" the leap second gradually across a day instead.

Negative timestamps: addressing time before the epoch

Because time_t is a signed integer, timestamps are not limited to dates after 1970 — they can go negative to point into the past, decreasing by one for every second before the epoch. Midnight on 1 January 1969 UTC is -31536000 (exactly one non-leap year earlier), and the most negative value a signed 32-bit field can hold, -2147483648, lands on 13 December 1901 at 20:45:52 UTC — the mirror image of the 2038 limit. Negative epochs are normal when storing historical dates, but they are a frequent bug source: a library or database column that assumes timestamps are unsigned will mis-handle anything before 1970, and some older systems reject negative values outright.

Sub-second precision: milliseconds, microseconds, nanoseconds

Plain Unix time has one-second resolution, but most platforms extend it, and the digit count is the quickest tell: a present-day value is 10 digits in seconds, 13 in milliseconds, 16 in microseconds and 19 in nanoseconds. JavaScript works natively in milliseconds — Date.now() returns a 13-digit value — so converting to classic seconds means dividing by 1,000. Python's time.time() returns a floating-point number of seconds with microsecond precision, while time.time_ns() returns an integer count of nanoseconds. Go's time.Now().UnixNano() and many databases likewise reach down to nanoseconds. Mixing these units is the single most common epoch bug — see the pitfalls below.

Reading the current epoch in any environment

Almost every language and shell exposes the current Unix time directly. The table below lists the idiomatic call in several common environments (each returns whole seconds unless noted):

Unix is not the only zero point

Different systems were designed around different epochs, which is why "seconds since an epoch" is meaningless until you know which epoch, and why timestamps are not portable between platforms without conversion. The most important reference points:

The Excel quirk is the classic gotcha: to stay bug-compatible with Lotus 1-2-3, Excel believes the non-existent date 29 February 1900 was real, so its day counter is off by one for any date in early 1900, and its effective epoch is pegged at 30 December 1899 to compensate. Windows uses 1601 because that year begins the 400-year cycle of the Gregorian calendar, making leap-year arithmetic clean.

Milestone timestamps and the 292-billion-year horizon

Because Unix time is just a counter, certain round or curious values have become minor geek holidays:

Past 2038 the long-term answer is already deployed: storing the count in a signed 64-bit integer pushes the overflow roughly 292 billion years in either direction of 1970 — comfortably beyond the projected lifetime of the Sun. Modern Linux, the C library and most languages moved to 64-bit time_t years ago; the residual 2038 risk lives in legacy 32-bit binaries, embedded firmware and old on-disk or on-wire formats that still pack the timestamp into 32 bits.

Common pitfalls when working with epochs

• Seconds vs. milliseconds. A 10-digit value is seconds; 13 digits is milliseconds. Feeding seconds to an API expecting milliseconds drops the date back into 1970, and the reverse flings it tens of thousands of years into the future.
• The missing (or extra) ×1000. JavaScript's new Date(n) expects milliseconds, so passing a seconds value needs n * 1000 — forgetting it is the most common epoch bug of all.
• Treating the epoch as local time. A Unix timestamp is always UTC. Rendering it without specifying a timezone silently shifts the displayed time by your machine's offset.
• Off-by-one rounding. Converting milliseconds to seconds should usually floor, not round, or an event can appear to happen a second after it actually did.
• Assuming unsigned. Dates before 1970 are negative; code or columns that assume non-negative timestamps will mangle historical data.

Wall-clock time versus monotonic time

One trap that catches even experienced developers: a Unix timestamp is wall-clock time, and wall-clock time can jump. NTP corrections nudge it forwards and backwards, an administrator can reset it, timezone-database updates shift the local rendering, and leap-second smearing deliberately slows or speeds it for a day. As a result, subtracting two Unix timestamps to measure how long an operation took can return a negative or wildly wrong duration if the clock was adjusted in between. For measuring elapsed time you should instead read a monotonic clock — one that only ever moves forward and is immune to wall-clock adjustments — such as performance.now() in the browser, time.monotonic() in Python, or CLOCK_MONOTONIC on Linux. Use the Unix epoch to record when something happened; use a monotonic clock to measure how long it took.

Why store the epoch instead of a formatted date

When you control the storage format, a raw Unix integer is almost always a better choice than a human-readable string. It is compact, sorts correctly as a plain number, is trivial to compare and do arithmetic on, and — crucially — carries no timezone ambiguity, because it is always UTC. A string such as "01/02/03" is hopeless by comparison: it could be three different dates depending on locale, and it cannot be subtracted. The standard interchange format when you do need text is ISO 8601 / RFC 3339 (for example 2009-02-13T23:31:30Z), whose trailing "Z" pins it to UTC and whose lexical order matches chronological order. The rule of thumb: store and transmit the epoch (or an explicit-UTC ISO 8601 string), and format it into local, human-friendly text only at the very last moment, in the user interface.

Frequently asked questions

What is a Unix timestamp?

A Unix timestamp (also called epoch or POSIX time) is the number of seconds that have elapsed since 00:00:00 UTC on 1 January 1970 (the "Unix epoch"), not counting leap seconds. It is a timezone-independent way to store an instant in time.

Is the timestamp in seconds or milliseconds?

Unix timestamps are classically in seconds (10 digits for current dates). JavaScript, Java and many APIs use milliseconds (13 digits). This tool lets you pick the unit, and auto-detects 13-digit input as milliseconds.

What is the Year 2038 problem?

Systems that store the timestamp in a signed 32-bit integer overflow on 19 January 2038 at 03:14:07 UTC, when the value exceeds 2,147,483,647. Modern 64-bit systems are unaffected; the fix is to store time in 64-bit integers.

Does the conversion happen on your servers?

No. It runs entirely in your browser with the native Date API, so your values are never uploaded. It also works offline once loaded.

Related tools

• Time unit converter
• Minutes in a month
• UUID Generator
• JSON Formatter & Validator
• Base64 Encoder / Decoder

See all developer & data conversions →