Timestamp Converter

Convert Unix timestamps to dates and back. Supports seconds, milliseconds, ISO 8601, and multiple timezones.

Convert Unix Timestamps

Current Time

live
Unix (seconds)1779625862
Unix (milliseconds)1779625862039
ISO 86012026-05-24T12:31:02.039Z
Local (UTC)24/05/2026 12:31:02
Relative0 seconds ago

Current Time Around the World

Los Angeles
05:31:02
Sun 24 May
New York
08:31:02
Sun 24 May
London
13:31:02
Sun 24 May
Paris
14:31:02
Sun 24 May
Kolkata
18:01:02
Sun 24 May
Shanghai
20:31:02
Sun 24 May
Tokyo
21:31:02
Sun 24 May
Sydney
22:31:02
Sun 24 May

What is a Unix timestamp (epoch time)?

A Unix timestamp, also called epoch time or POSIX time, is the number of seconds that have elapsed since 00:00:00 UTC on 1 January 1970 — a moment programmers call “the epoch”. Crucially, it ignores leap seconds, so it counts a steady stream of seconds rather than tracking the messy reality of astronomical time. Its appeal is simplicity: a single integer represents an exact instant anywhere on Earth, with no timezone, no daylight-saving ambiguity, and no locale-specific formatting to trip over. That makes timestamps ideal for storing dates in databases, comparing two events, sorting records, computing durations, and exchanging times between systems written in different languages. When you need to show that instant to a human, you convert it — exactly what this tool does — into an ISO string, a localised date, or a friendly “3 hours ago” relative phrase.

Seconds vs milliseconds, and the Year 2038 problem

Classic Unix time is measured in seconds, which is a ten-digit number today and stays ten digits until the year 2286. JavaScript, Java, and many JSON APIs instead use milliseconds (thirteen digits), because Date.now()returns the count since the epoch in ms. Mixing the two is a classic bug: feed a seconds value into a milliseconds API and you land in 1970; do the reverse and you jump to the year 50,000+. This tool auto-detects by magnitude, treating values above twelve digits as milliseconds. A related gotcha is the Year 2038 problem: systems that store time in a signed 32-bit integer overflow on 19 January 2038, exactly 2³¹ seconds after the epoch, and wrap around to 1901. Modern 64-bit timestamps push that limit roughly 292 billion years out, but legacy embedded devices and old file formats can still bite — if you ever see nonsense dates near 2038, suspect 32-bit time.

ISO 8601 and timezone handling

ISO 8601 is the international standard for writing dates and times as text, in the form 2026-04-15T14:30:00Z. It is unambiguous, sorts correctly as a plain string, and is understood by virtually every programming language and API. The trailing Z (“Zulu”) means UTC; an offset such as +01:00marks a specific timezone. The key mental model is that a timestamp represents one fixed instant — the underlying value never changes — while the timezone only affects how that instant is displayed. New York and Tokyo see the same Unix number at the same moment; they just render different wall-clock times. Use the timezone selector and world-clock panel above to sanity-check how an instant appears in different regions, and prefer storing and transmitting times in UTC, converting to local time only at the very edge where you present them to a user.

Frequently Asked Questions

Find this useful?

These tools are free and ad-free. Support the project!

Buy me a coffee

Related Tools