Unix time — also called Epoch time — is the number of seconds that have elapsed since 00:00:00 UTC on 1 January 1970, excluding leap seconds. It is the universal way software tracks time: single integer, no timezone ambiguity, arithmetic as simple as adding and subtracting numbers. This converter takes a timestamp (in seconds, milliseconds, or microseconds) and shows the equivalent date in both UTC and your local timezone, and goes the other direction from a date picker back to an integer.

How Unix time works

Instead of storing a date as a structured record (year, month, day, hour, minute, second, timezone), Unix time stores the number of seconds since a fixed reference point. The consequences are deep:

Platform independent — the same integer means the same instant on Windows, macOS, Linux, embedded firmware, and every database.
Arithmetic is trivial — the time 24 hours from now is now() + 86400. The time 90 days from now is now() + 90 * 86400.
No DST, no timezone — an Epoch timestamp always refers to a point in UTC. The local-time interpretation happens only at the display layer.
Cheap to store and index — a single 64-bit integer is smaller and faster to sort than any string representation.

Seconds, milliseconds, microseconds, nanoseconds

Not every system uses the same precision. You will encounter four variants:

Seconds (10 digits for dates in the 2000s–2030s, e.g. 1710668400) — classic Unix, most database columns, time() in C, time.time() in Python, Date::Now in Rust’s time crate.
Milliseconds (13 digits, e.g. 1710668400000) — Date.now() in JavaScript, System.currentTimeMillis() in Java, most web APIs and JSON payloads.
Microseconds (16 digits) — high-precision logging, some telemetry systems, PostgreSQL’s timestamp with 1 µs resolution.
Nanoseconds (19 digits) — Go’s time.Now().UnixNano(), hardware timestamps.

This tool auto-detects the unit from the number of digits and converts accordingly. If a timestamp looks “decades off,” it is almost always a unit mismatch — a 13-digit millisecond value fed into a seconds-expecting parser will land in the year 56,053.

Why timestamps drift between systems

If you see a 1-second or 1-hour offset between two logs, a few things could be happening:

Seconds vs milliseconds confusion — one producer divides by 1,000, the other does not.
Local time mistakenly persisted — a developer converted to local time before storage, dropping the zone.
Clock skew — machines whose NTP sync has drifted. Typical drift on a modern server is under 10 ms, but embedded devices can drift minutes per day without NTP.
Leap seconds — most systems smear or ignore them; a few strictly observe them, producing sub-second gaps on leap-second days (the last was 2016).

The Year 2038 problem

Many older systems store Unix time as a signed 32-bit integer, which runs out of room at 2^31 − 1 = 2,147,483,647 seconds — 03:14:07 UTC on Tuesday, 19 January 2038. After that second, the integer overflows and wraps around to a negative value, which most date libraries interpret as 13 December 1901. This is not a theoretical concern: embedded systems, automotive firmware, industrial controllers, and some legacy database schemas still use 32-bit time.

Modern 64-bit Unix time will not overflow until the year 292,277,026,596, so any new code should use 64-bit integers.

How to use this tool

See the current timestamp in the top display — it ticks in real time.
Timestamp to date: paste a number into the input; the tool picks up the unit from the digit count and shows both UTC and local equivalents.
Date to timestamp: use the date picker to select any date and time; the tool outputs the corresponding seconds and milliseconds integers.

Worked examples

The start of the year 2000: 946684800 seconds (UTC).
The Y2038 boundary: 2147483647 seconds.
Your birthday at 12:00 local time, 15 May 1995: enter that date in the picker; for UTC+2, the tool shows 800532000 seconds.

Frequently asked questions

Why is my timestamp showing the wrong date?

The most common cause is a unit mismatch. A 13-digit millisecond value interpreted as seconds lands tens of thousands of years in the future. A 10-digit second value interpreted as milliseconds lands in January 1970. This tool auto-detects the unit; if you are hand-coding a converter, always confirm the unit of your input.

How do I convert a timestamp in another language?

JavaScript: new Date(ms) or new Date(seconds * 1000)
Python: datetime.fromtimestamp(seconds, tz=timezone.utc)
Go: time.Unix(seconds, 0).UTC()
SQL (PostgreSQL): to_timestamp(seconds) or to_timestamp(ms / 1000.0)
Bash: date -u -d @1710668400

Does Unix time include leap seconds?

Strictly, no. POSIX defines Unix time as “the number of seconds since the epoch, excluding leap seconds,” which is what almost every language and OS implements. A handful of systems (notably the TAI family) do include them, but when you read “Epoch time” or “Unix time,” assume leap seconds are ignored or smeared.

What about timezone?

Unix time is always UTC. Whatever timezone you see in your display is a rendering choice. When storing timestamps in a database, store the Epoch integer and render in the user’s zone at read time — never store “local time plus zone” as two separate columns.

Is there a negative Unix time?

Yes. Dates before 1970 are represented as negative integers. -86400 is 31 December 1969, 00:00 UTC. Most databases and languages handle this correctly.

Privacy note

Conversions happen in your browser. The current timestamp is derived from your device clock; no data leaves your device.

Epoch Converter