Timestamp Converter

What a Unix timestamp is

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 date chosen because it was a convenient round number for early Unix systems. It counts forward for later moments and, in some systems, backwards into negative numbers for earlier ones.

Because it is a single integer with no timezone attached, it is the most portable way to store a moment in time: the same timestamp means the same instant in Shanghai, London and New York. Timezones only appear when you *display* it.

Seconds or milliseconds?

Both are common in practice, and telling them apart is the usual source of bugs:

• 10 digits — seconds, used by Linux, PHP, Python and most APIs. `1700000000` is 14 November 2023.
• 13 digits — milliseconds, used by JavaScript's `Date.now()`, Java, and most mobile and browser APIs. `1700000000000` is the same moment.

This converter auto-detects the unit from the digit count. If you paste something ambiguous, set the unit manually — passing seconds into an API that expects milliseconds lands you in 1970, and passing milliseconds where seconds are expected jumps you 50,000 years into the future.

Converting in code

• JavaScript: `Math.floor(Date.now() / 1000)` for seconds; `new Date(ts * 1000)` to convert back.
• Python: `time.time()` returns float seconds; `datetime.fromtimestamp(ts)` converts (and applies the local timezone unless you use `utcfromtimestamp`).
• PHP: `time()` returns seconds; `date('Y-m-d H:i:s', $ts)` formats them.
• SQL: `FROM_UNIXTIME(ts)` in MySQL, `to_timestamp(ts)` in PostgreSQL.

Practical notes and traps

• Timestamps are UTC. A timestamp rendered as 08:00 in Shanghai and 00:00 UTC is the same number — store timestamps, format for display.
• Mind the unit on both ends. The most common real bug is mixing seconds and milliseconds between a frontend and its API.
• The 2038 problem. Systems that store a timestamp in a signed 32-bit integer overflow on 19 January 2038 at 03:14:07 UTC. Migrating to 64-bit (or milliseconds in 64-bit) removes the limit; JavaScript has no such problem today because numbers are 64-bit floats.
• Leap seconds are ignored. Unix time pretends every day has exactly 86,400 seconds, so it drifts from UTC by a second or so over decades. This matters for astronomy, almost never for applications.
• Durations are not timestamps. A 90-minute video is 5,400 seconds — a duration, not a moment in time. Do not store durations as epoch values.

Privacy

All conversions happen locally in your browser, so log lines, database values and internal timestamps you paste are never uploaded.

FAQ

How do I tell whether a timestamp is in seconds or milliseconds?

Count the digits. 10 digits is seconds (about 1.7 billion today) and 13 digits is milliseconds (about 1.7 trillion). A quick sanity check: a 10-digit value in the 1.6–1.8 billion range is roughly today, and the same instant in milliseconds is that number with three more zeros.

Why does the same timestamp show different clock times?

Because a timestamp has no timezone — it is an absolute instant. The same number is 00:00 UTC, 08:00 in Shanghai and 16:00 (the previous day) in Los Angeles. Compare the UTC line if you want a timezone-independent answer, and the local line if you want what a user in that region saw.

What happens after 2038?

Systems that store seconds in a signed 32-bit integer overflow on 19 January 2038 at 03:14:07 UTC and wrap to 1901. Migrating those fields to 64-bit — or storing milliseconds in 64-bit, as JavaScript and most modern APIs do — pushes the limit hundreds of billions of years away. If you maintain older C, PHP or database code, audit those columns before 2038.

Is Unix time affected by leap seconds?

Unix time deliberately ignores leap seconds: it assumes every day has exactly 86,400 seconds. Over decades this makes it differ from UTC by roughly a second. For logging, scheduling and storing application data this is irrelevant; only fields that depend on precise astronomical timing need care.