Unix Timestamp Converter Online — Epoch Time to Date Free

A Unix timestamp (also called epoch time) is the number of seconds that have elapsed since January 1, 1970, 00:00:00 UTC. It is the universal standard for representing time in computing systems.

Why Unix timestamp?

Before Unix time, every system used different date formats and timezones — making date arithmetic across systems a nightmare. Unix time solves this by storing a single integer that is unambiguous anywhere in the world. Converting to a local timezone happens at display time, not at storage time.

Key Unix timestamps

The Year 2038 problem

32-bit systems store Unix timestamps as a signed 32-bit integer, which maxes out at 2,147,483,647 — January 19, 2038. After that, it overflows to a large negative number. Modern 64-bit systems don't have this problem (their overflow is ~292 billion years from now), but embedded systems and older databases may still be affected.

Seconds vs milliseconds

Many systems (JavaScript, Java, Android) use milliseconds instead of seconds. A millisecond timestamp is roughly 1000x larger:

• Seconds: 1700000000 (10 digits)
• Milliseconds: 1700000000000 (13 digits)

If a timestamp has 13 digits, divide by 1000 to get seconds. Our converter auto-detects this.

How to convert Unix timestamp online

Timestamp → Date:

1. Go to Unix Timestamp Converter
2. Enter the timestamp in the input field
3. Select your timezone from the dropdown
4. The human-readable date and time appears instantly

Date → Timestamp:

1. Switch to the Date → Timestamp tab
2. Enter a date and time
3. Select your timezone
4. The Unix timestamp in both seconds and milliseconds is shown

Using Unix timestamps in code

// JavaScript — current timestamp in seconds
Math.floor(Date.now() / 1000)

// JavaScript — current timestamp in milliseconds
Date.now()

// Convert timestamp to Date object
new Date(1700000000 * 1000)

// Python
import time
int(time.time())

Why leap seconds make Unix time slightly fictional

Unix time is defined as the number of seconds since 1970-01-01 UTC — but with a deliberate simplification: every day contains exactly 86,400 seconds.

Real solar days do not. Earth's rotation is irregular, so leap seconds are occasionally inserted to keep UTC aligned with astronomical time. Unix time has no way to represent one. Systems handle this by either repeating a timestamp value or "smearing" the extra second across several hours.

The practical consequence: Unix time is not a true count of elapsed SI seconds since 1970 — it is off by the number of leap seconds inserted since. For almost everything this is irrelevant. For high-precision timing, financial sequencing, or anything comparing intervals across a leap second, it matters, and it has caused real outages when systems saw time move backwards.

The 2038 problem is already here

A signed 32-bit integer overflows on 19 January 2038 at 03:14:07 UTC, wrapping to 1901. The failure is often described as a future problem, but any system doing date arithmetic forward hits it early — a 20-year mortgage term calculated in 2019 already crossed the boundary.

64-bit time handles roughly 292 billion years and is standard on modern systems. The remaining exposure is in embedded devices, older databases, file formats with fixed-width 32-bit time fields, and code that casts to int somewhere in the middle of an otherwise 64-bit pipeline.

Seconds versus milliseconds

This is the single most common bug involving timestamps.

• Unix convention: seconds. What most APIs, databases, and JWT exp claims use.
• JavaScript: milliseconds. Date.now() returns milliseconds.

Mixing them silently produces absurd results rather than errors:

new Date(1787184000)        // 1970-01-21 — treated as ms
new Date(1787184000 * 1000) // 2026-08-20 — correct

Quick check by digit count: a 10-digit timestamp is seconds; 13 digits is milliseconds. Anything landing in 1970 means you divided when you should have multiplied, or the reverse.

Storing time correctly

Three rules that prevent most timezone bugs:

1. Store instants in UTC. Convert to local time only for display. A timestamp with no zone is ambiguous data.
2. Do not store calendar dates as timestamps. A date of birth or a public holiday is a calendar date, not an instant — storing it as a timestamp makes it shift across zones.
3. Store future appointments as local time plus a zone identifier, not as a UTC instant. Governments change timezone rules, and a meeting set for "9am in Berlin next year" should stay at 9am even if the offset changes.

That third rule surprises people. A UTC instant is correct for something that already happened, and wrong for a future wall-clock commitment.

Frequently asked questions

Why 1 January 1970?

An arbitrary but convenient choice by early Unix developers — recent enough to keep numbers small on limited hardware, and far enough back to cover the dates the systems needed.

Can Unix timestamps be negative?

Yes. Negative values represent times before 1970, so −86400 is 31 December 1969. Some libraries handle negative timestamps poorly, which is a common source of bugs with historical dates.

What is ISO 8601 and when should I use it instead?

2026-08-20T03:16:08Z is human-readable, unambiguous, sorts correctly as plain text, and carries its zone. Prefer it for APIs, logs, and anything a person may read. Unix timestamps are better for arithmetic and compact storage.

Does Unix time account for daylight saving?

No, and that is the point. It is always UTC. DST is applied when converting to local time for display, which is why storing UTC and converting late avoids most DST bugs.

Why does my timestamp show the wrong hour?

Almost always a timezone conversion applied twice, or not at all. Check whether the value was already local before conversion.

Convert Unix timestamps free →