Unix Timestamp & Epoch Converter

How to use this date-time converter

1. Type a Unix timestamp in seconds or milliseconds, click "Use current time", or pick a date & time directly.
2. Every format (seconds, milliseconds, ISO 8601, UTC, local time, relative) updates instantly and stays in sync.
3. Copy whichever format your system or API needs.

What is a Unix timestamp?

A Unix timestamp counts the number of seconds elapsed since January 1, 1970 (UTC), known as the Unix epoch. It's a compact, timezone-independent way to store dates in databases and APIs.

How Unix time works under the hood

Under the hood, a Unix timestamp is just a signed integer: the number of seconds (or milliseconds) since 00:00:00 UTC on January 1, 1970, ignoring leap seconds entirely. That last detail matters — official UTC has inserted 27 leap seconds since 1972 to keep atomic clocks in sync with the Earth's slowing rotation, but Unix time pretends none of them happened, so it isn't a perfect count of elapsed physical seconds. In practice this discrepancy is invisible for almost every application; it only matters for systems that require sub-second precision synchronized to astronomical time, like some scientific instruments.

The classic "Year 2038 problem" comes from how this integer used to be stored: 32-bit signed systems can only represent timestamps up to 2,147,483,647 seconds after the epoch, which overflows on January 19, 2038. Modern 64-bit systems (essentially everything built since the mid-2010s) don't have this ceiling, but some embedded devices, older databases, and legacy file formats still use 32-bit timestamps internally, which is why the date still shows up in migration checklists.

Seconds vs. milliseconds: the classic bug

The single most common bug involving Unix time isn't a timezone mistake — it's mixing up seconds and milliseconds. JavaScript's Date object expects milliseconds (new Date(1700000000000)), while most server-side languages, Unix command-line tools, and many REST APIs return seconds (1700000000). Feed a seconds-based timestamp into a function expecting milliseconds and you'll get a date sometime in 1970, since the value is a thousand times too small. Feed a milliseconds value into something expecting seconds and you'll get a wildly far-future date — sometimes literally decades or centuries out.

This converter avoids the guesswork by following the standard convention: any input below 100,000,000,000 is treated as seconds (10-digit range), anything larger as milliseconds (13-digit range). That threshold works because current timestamps are 10 digits in seconds and 13 in milliseconds, and the two ranges don't overlap for any date within a normal human lifetime in either direction.

When to use Unix time vs. ISO 8601

Unix time and ISO 8601 (like 2026-09-06T14:30:00Z) solve different problems. Unix time is a plain number — cheap to store, trivial to compare (a > b really does mean "later"), and immune to string-parsing ambiguity, which is why it's the default for database columns, log timestamps, cache expiry, and internal API payloads. ISO 8601 is meant to be read: it's the right choice for anything a human will look at directly — user-facing dates, configuration files, exported reports — and for any interchange format where you want the date to remain unambiguous without a shared reference table for what the number means.

A practical rule: store and compute with Unix time, display and configure with ISO 8601 or a localized format. Mixing the two inside the same system — say, storing timestamps as numbers in one table and as strings in another — is a common source of subtle sorting and comparison bugs.

Common mistakes when working with timestamps

Beyond the seconds/milliseconds mix-up, a few mistakes show up constantly in real codebases. Treating a "local time" value as if it were UTC (or vice versa) is probably the second most common — this happens when a timestamp is generated on a server in one timezone and later interpreted by a client in another without an explicit UTC marker. Scheduling logic is especially exposed to this: a cron job or reminder set for "9 AM" needs to specify a timezone, or it silently shifts by an hour twice a year in any region that observes Daylight Saving Time.

Another frequent issue is assuming a Unix timestamp can represent any date at all. Very old dates (long before 1970) require negative timestamps, which not every library or database column handles correctly, and very distant future dates can overflow specific storage types even on 64-bit systems, depending on how the value is encoded downstream.

Limitations of this converter

This tool runs entirely in your browser using JavaScript's built-in Date object, which brings a few practical limits worth knowing. It doesn't account for leap seconds, since neither Unix time nor the Date object represents them. "Local time" always reflects your device's current timezone and DST rules — if you need to see a timestamp as it would appear in a different city, you'll need a timezone-aware converter instead of the one on this page. And while the seconds/milliseconds auto-detection covers every realistic date, entering a timestamp far enough in the past or future (many millennia away) can push against the practical range of JavaScript's date handling, even though the underlying type is technically capable of representing much larger spans.