Skip to content

Unix Timestamp Converter

Timestamp → readable date, or date → timestamp. Both directions, both units, every zone.

A Unix timestamp is the number of seconds (or milliseconds) since 1970-01-01 00:00:00 UTC — the standard way computers represent an instant in time. The converter below handles both directions: type a number to see the corresponding UTC and local-time rendering, or pick a date to get the timestamp. The live clock at the top is the current timestamp on your machine, updating every second.

Current Unix timestamp

1778972513 s/ 1778972513212 ms

Timestamp → date

UTC (ISO 8601):2026-05-16T23:01:53Z
Local (UTC):2026-05-16, 23:01:53

Date → timestamp

Unix seconds:1778972460
Unix milliseconds:1778972460000

How to use

  1. Timestamp → date

    Paste a Unix timestamp into the left card. Pick seconds (e.g. 1779000000) or milliseconds (e.g. 1779000000000). The widget renders the UTC ISO 8601 form and your local-zone wall-clock equivalent.

  2. Date → timestamp

    Pick a date and time in the right card. Choose the timezone the date represents (your machine's zone by default). The widget computes the corresponding Unix seconds and milliseconds.

  3. Copy the format you need

    Each output has a one-tap copy button. ISO 8601 for human-readable storage, Unix seconds for protocols, Unix milliseconds for JavaScript.

Reference points

MomentUnix seconds
Unix epoch (1970-01-01)0
2000-01-01946,684,800
2020-01-011,577,836,800
2025-01-011,735,689,600
Year 2038 (32-bit overflow)2,147,483,647
3000-01-0132,503,680,000

Frequently asked questions

What's the difference between Unix seconds and milliseconds?
Both count from the same epoch (1970-01-01 UTC). Most C/Unix tools, databases, and APIs use seconds; JavaScript's Date.now() and many modern web APIs use milliseconds. Multiply seconds by 1000 to convert to milliseconds; divide milliseconds by 1000 to convert to seconds.
Why does my timestamp produce a different date in different zones?
It doesn't — the timestamp is the same instant everywhere. What changes is the wall-clock rendering. Unix timestamp 1779000000 is the same instant whether you're in NYC or Tokyo, but it shows as different local clock times.
What is the Year 2038 problem?
A 32-bit signed integer of seconds overflows on 2038-01-19 at 03:14:07 UTC. Systems using 32-bit time_t will wrap around or crash. Modern operating systems use 64-bit time_t which is safe for billions of years. Embedded systems and old database schemas may still be affected.
Does this handle negative timestamps?
Yes. A negative Unix timestamp represents a date before 1970-01-01. -2208988800 is 1900-01-01. The widget renders these correctly though they're rare in practice.
What about leap seconds?
Unix time ignores leap seconds. A Unix timestamp represents the number of non-leap seconds since the epoch. At the moment a leap second is inserted, the timestamp is technically ambiguous. Most production systems handle this with a 'leap smear' — spreading the leap second across many hours rather than inserting it at one instant.
Does the converter handle high-precision timestamps?
It accepts seconds or milliseconds. For microsecond or nanosecond timestamps (common in distributed tracing and high-frequency data), divide by 1000 or 1,000,000 to get milliseconds and paste that in. Microsecond-level precision isn't displayed; the use case is rare in user-facing date math.

About

Why 1970?

When Unix was being developed at Bell Labs in 1970-71, the implementers needed an epoch close to the present so signed integers wouldn't overflow during the system's lifetime. 1970-01-01 was the recent start of a decade and made arithmetic with year 1970 dates work without negative numbers. The choice has stuck for 55+ years, despite occasional proposals to move to other epochs (Y2038 mitigation efforts, NTP's 1900 epoch, etc.).

Where to use which

Unix timestamps are the right format whenever you need to store, transmit, or compare instants in time without ambiguity. ISO 8601 ("2026-05-16T13:30:00Z") is the right format when humans need to read the value. Convert between them at the boundary — store as timestamp, display as ISO 8601 or localised wall-clock.