What is a Unix timestamp?

A Unix timestamp (also called epoch time, POSIX time or Unix epoch) counts the number of seconds that have elapsed since 1970-01-01 00:00:00 UTC — “the epoch”. The value 0 is that exact instant; 1729000000 is 2024-10-15 13:46:40 UTC; and negative values count backwards into 1969 and earlier. Because the count is anchored to UTC, a timestamp carries no timezone of its own: the same number is 23:46 in Sydney, 14:46 in London and 09:46 in New York, and only the display changes when you apply a timezone.

That timezone-freeness is exactly why timestamps are the lingua franca of APIs, databases and log files: two servers in different cities can agree on “when” without ever exchanging clock offsets. The price is that a raw number in a log line tells you nothing unless you know its unit and remember to render it in the right zone.

Seconds, milliseconds, microseconds, nanoseconds

Most systems store epoch time in seconds, but plenty of ecosystems use finer units — and they all look like “a big number” in a log. The digit count is the reliable tell:

Unit	Typical digit count	Where you'll meet it
seconds	10 (until 2286)	C time(), most REST APIs, file mtimes, JWT iat/exp
milliseconds	13	JavaScript Date.now(), Java System.currentTimeMillis(), many web APIs
microseconds	16	PostgreSQL epoch columns, some database and telemetry formats
nanoseconds	19	Python time.time_ns(), Go UnixNano(), high-resolution tracing

This converter auto-detects the unit from the digit count, the same heuristic you would apply by hand — and you can override it with the unit selector if a value is ambiguous or comes from an unusual source.

UTC vs local time — the classic bug

The single most common timestamp bug is mixing the two: a log says 12:00:00 and someone assumes it's UTC when it was actually local (or vice versa), and every downstream calculation is off by the timezone offset. The discipline is: store and transmit in UTC, convert to local only at the moment of display. Daylight-saving transitions make this worse — a “13-hour” day is a display artefact, not a data problem, as long as the underlying epoch value is untouched.

The Y2038 problem

On 32-bit systems, epoch seconds are usually a signed 32-bit integer, which overflows at 2038-01-19 03:14:07 UTC (2³¹ seconds after the epoch). After that instant, 32-bit time_t values wrap to negative and dates jump back to 1901. 64-bit systems are immune for practical purposes — their range runs to the year 292,278,994 AD — which is why 64-bit time_t is now the default everywhere, but embedded and legacy 32-bit devices are still in the field.

Where you'll meet Unix timestamps

• API payloads — created_at, updated_at, expires fields, in seconds or milliseconds depending on the vendor.
• JWTs — iat (issued at), exp (expiry) and nbf (not before) are seconds since the epoch.
• Log lines — application and access logs frequently open with a raw epoch number, which is what the log-line parser above is for.
• File systems — stat mtimes are epoch seconds (many file systems also keep sub-second fractions).
• Databases — epoch columns in seconds or milliseconds, or UTC datetime columns that are just a formatted epoch.
• HTTP — Date and Last-Modified headers use RFC 2822 text, but cache and expiry arithmetic is done against epoch time.

Convert from the command line instead

• GNU date (Linux): date -u -d @1729000000 — and date +%s to print the current timestamp
• BSD date (macOS): date -u -r 1729000000
• Python: datetime.fromtimestamp(1729000000, timezone.utc)
• JavaScript: new Date(1729000000 * 1000) — note the ×1000, JS works in milliseconds

Common pitfalls

• The 1000× bug. A timestamp in milliseconds fed to a seconds API (or vice versa) lands in 1970 or year 33,000. The digit count is your first check — 10 digits is seconds, 13 is milliseconds.
• Pre-1970 is negative. Some code paths (especially 32-bit unsigned) break on negative epoch values; if a date before 1970 shows as year 1901 or 2038, suspect a signed/unsigned mix-up.
• Floating-point seconds lose precision. 1729000000.123456 stored as a double starts losing sub-millisecond detail; if you need sub-second precision, use integer milliseconds or microseconds.
• Don't “fix” the zone in storage. Converting a timestamp to local time before saving it bakes in a timezone that may be wrong later (DST, travel, a different reader). Keep the epoch, render the zone.
• ISO 8601 without a zone is ambiguous. 2025-10-14T12:00:00 has no UTC marker; parsers (including this tool's log parser) fall back to local time. Prefer an explicit Z or offset.

Nothing on this page leaves your browser: detection, conversion, formatting, copying and log parsing all happen locally, with no server round-trip and no storage of any kind.