Unix Timestamp Converter

Convert between Unix timestamps and human-readable dates in both directions. All conversion happens locally in your browser — nothing is uploaded.

Results appear here

What is a Unix Timestamp?

A Unix timestamp counts the number of seconds since January 1, 1970 00:00:00 UTC (the "Unix epoch"), not counting leap seconds. Most systems store timestamps as 32-bit or 64-bit integers: 10 digits for seconds, 13 digits for milliseconds. JavaScript's Date.now(), Python's time.time(), and MySQL's UNIX_TIMESTAMP() all produce variants of this value.

Common Use Cases

  • Debugging logs: Server logs often print raw timestamps — convert them to read what time an error actually occurred.
  • API responses: Many JSON APIs return "created_at": 1728000000 instead of an ISO date.
  • Database queries: Filter by date ranges using UNIX_TIMESTAMP() in MySQL or EXTRACT(EPOCH FROM ...) in PostgreSQL.
  • JWT & token expiry: JWT claims carry exp and iat as Unix seconds — verify them before debugging auth issues.
  • Signed URLs: Cloud storage presigned URLs embed an expiry timestamp; convert it to know when access lapses.

šŸ’” Pro Tip: Seconds vs. Milliseconds

The classic bug: JavaScript and Java use milliseconds (13 digits, e.g. 1728000000000), while Go, PHP, Python, and most databases use seconds (10 digits, e.g. 1728000000). A 13-digit value passed to a seconds-only API is off by a factor of 1000 — usually landing in 1973 or the year 5138. When in doubt, this tool's Auto-detect mode tells you which unit a value looks like.

Frequently Asked Questions

Why does my timestamp convert to 1970 or 5138?

You're mixing units. A seconds-value read as milliseconds (multiplied by 1000) lands near 1970; a milliseconds-value read as seconds lands in the year 5138. Check the digit count: 10 digits = seconds, 13 digits = milliseconds. Auto-detect handles this automatically.

Is a Unix timestamp timezone-dependent?

No. A Unix timestamp is an absolute point in time — the same integer represents the same instant everywhere on Earth. Only the displayed date changes with your timezone. This converter shows your local time and UTC side by side so you can see both.

How do I get the current timestamp in code?

JavaScript: Math.floor(Date.now() / 1000) for seconds (or Date.now() for ms). Python: int(time.time()). Go: time.Now().Unix(). PHP: time(). MySQL: SELECT UNIX_TIMESTAMP();. PostgreSQL: SELECT EXTRACT(EPOCH FROM now());. Bash: date +%s.

What about dates before 1970?

They're valid too — negative timestamps. The Unix epoch is just a reference point; -86400 is exactly one day before the epoch (1969-12-31 UTC). 32-bit signed integers cover 1901–2038, which is why the Year 2038 problem affects old systems: they'll overflow at 03:14:07 UTC on January 19, 2038.

Is ISO 8601 better than a Unix timestamp?

For storing in JSON, ISO 8601 strings (e.g. 2026-10-04T12:30:00Z) are human-readable and unambiguous about timezone — but parsing them costs CPU and string handling. Unix timestamps are compact, trivially sortable, and timezone-free. Many teams store UTC ISO strings in databases and convert to Unix seconds only at API boundaries. Either works if you pick one consistently.

Why is my date math off by an hour — or a whole day?

Because you're assuming a day is always 86400 seconds. Timezone-aware APIs do the same: Instant.plus(Duration.ofDays(1)) in Java, time.Now().Add(24 * time.Hour) in Go, and new Date(ts + 86400e3) in JS all add exactly 86,400 seconds — so across a DST change you land one hour off, and any date rollover at midnight can shift by a full day. A spring-forward day is 82,800 seconds; a fall-back day is 90,000. Add calendar units instead (ZonedDateTime.plusDays(1), time.Time.AddDate(0,0,1)) or do the arithmetic in UTC and convert to local time only for display.

Can I use a timestamp to measure how long something took?

Not reliably. Date.now(), time.time(), and friends read the wall clock, which NTP can step backwards (or forwards) mid-measurement — a job that took 400 ms can appear to take -2000 ms. Use a monotonic clock for durations: performance.now() in the browser, time.monotonic() in Python, performance.now() / process.hrtime.bigint() in Node, System.nanoTime() in Java, time.Since(start) in Go. Keep wall-clock timestamps for when things happened, monotonic clocks for how long.

Will 10-digit timestamps ever run out?

Seconds-since-epoch reaches 11 digits at 10000000000 = 2286-11-20T17:46:40Z, so digit-count heuristics have a long shelf life. The nearer cliff is the signed 32-bit overflow on 2038-01-19 (the Year 2038 problem) — anything storing seconds in a 32-bit int breaks then, which is why 64-bit columns (bigint / long) are the safe default.