Convert between Unix timestamps and human-readable dates — supports seconds and milliseconds.

What it does

This tool converts between Unix timestamps and human-readable dates and times, in both directions. Switch to Timestamp → Date to turn a number of seconds since 1970 into an ISO 8601 UTC date, or Date → Timestamp to turn a UTC date and time back into a timestamp. Everything runs in your browser — nothing you paste is sent anywhere — and the same instant is shown alongside in your local time zone for quick sanity-checks.

What is a Unix timestamp?

A Unix timestamp is a whole number: the count of seconds that have elapsed since 1970-01-01 00:00:00 UTC, the moment known as the epoch. Every later instant is a positive count; every earlier instant is a negative count. Because a timestamp is just an integer, it needs no time zone, no locale, and no calendar rules — those only enter when you render it back into a date. The same value is sometimes called epoch time, POSIX time, or simply seconds since epoch.

Worked example

The timestamp 1700000000 corresponds to 2023-11-14T22:13:20Z — that is, 22:13:20 UTC on 2023-11-14. Going the other way, entering 2023-11-14 at 22:13:20 UTC gives back 1700000000 exactly. The round-trip is lossless because both representations describe the same underlying instant.

Seconds versus milliseconds

Most systems count timestamps in seconds: Unix, PHP time(), Python time.time(), database UNIX_TIMESTAMP(), cron schedules. JavaScript is the notable exception — Date.now() returns milliseconds. That mismatch is the single most common source of "wrong by a factor of 1000" bugs.

You can tell them apart by digit count. In the current era, a timestamp in seconds has about ten digits (a value around 1.7×10⁹); the same instant in milliseconds has about thirteen. This tool treats any input with an absolute value of 10¹² or more as milliseconds and divides accordingly, so pasting either style just works.

Time zones and daylight saving

A timestamp has no time zone — it is a single instant on a global clock. Time zones only matter when a timestamp is rendered back into a wall-clock date. The tool shows the UTC representation as its primary output because UTC is the neutral, unambiguous form used in APIs, logs, and databases. The local-time line below is a convenience: it re-renders the same instant using your browser's zone (including any daylight-saving offset in effect on that date), so you can see what that timestamp meant "at your desk".

Daylight saving never changes a timestamp — it changes only the label your local clock puts on it. Two ISO strings can differ by an hour and still describe the same instant if one is in summer time and the other in winter time.

Common uses

Log timestamps. Web-server and application logs record events by epoch time so they sort and compare cleanly across machines in different zones.
Databases. Many schemas store created_at and updated_at as integer timestamps rather than formatted strings — cheaper to store, faster to compare, immune to locale.
API tokens. JSON Web Tokens (JWT) carry iat ("issued at") and exp ("expires") as Unix timestamps in seconds. If a JWT is being rejected as expired, converting exp here often reveals the problem in one glance.
Cron and scheduling. Anywhere a job needs to fire at a specific instant regardless of zone, timestamps are the wire format.
File and record ordering. Naming files or records with an epoch prefix (1700000000-report.pdf) gives you a sort order that matches chronological order.

Frequently asked

Why is 1970 the epoch?

Unix was born at Bell Labs at the start of the 1970s. Its designers needed a zero-point for their clock and picked the beginning of the year they were working in: midnight on 1 January 1970, UTC. The choice was arbitrary — but once it was baked into POSIX and every Unix-descended system, it stuck. Every timestamp on the internet today is measured from that same instant.

What is the Year 2038 problem?

A signed 32-bit integer can hold values up to 2,147,483,647. In seconds since 1970 that number is reached at 03:14:07 UTC on 19 January 2038 — one second later, a 32-bit signed timestamp overflows to a large negative number, which usually renders as a date in 1901. Any system still using a 32-bit epoch clock will misbehave then. The fix is to use 64-bit timestamps, which push the ceiling billions of years into the future; modern operating systems, languages, and databases have all moved. Legacy embedded firmware is the main risk.

Can a timestamp be negative?

Yes. Negative values simply count seconds before the epoch. A timestamp of -1 is 1969-12-31 23:59:59 UTC, one second before 1970. Not every language or database accepts them, but the concept is well-defined and this tool renders them correctly.

Does this tool handle leap seconds?

No — and neither does the Unix timestamp itself. POSIX time deliberately pretends leap seconds don't exist: every UTC day is treated as exactly 86,400 seconds, and the extra second inserted every few years is smeared away by the system clock. That keeps timestamps easy to arithmetic on, at the cost of a tiny (sub-second) drift from strict atomic time.

You can read how every ToolHare tool is checked on the how we build and verify tools page.

Unix Timestamp Converter