Unix Timestamp Converter

Unix Timestamp Converter

Updated August 27, 2026

Ten digits is seconds. Thirteen is milliseconds.

Ten digits is seconds. Thirteen is milliseconds. Mix them up and you get 1970, or the year 56000, and then you debug the database for an hour.

Paste a timestamp, a date, or now. Read the unit first. If the number is 13 digits, it is not what Postgres to_timestamp wants.

How to use it

  1. Seconds are 10 digits (until 2286). Milliseconds are 13. Microseconds are 16. If you aren't sure, check the length before you convert.
  2. Y2038 is real on 32-bit time_t. 2147483647 is 2038-01-19 03:14:07 UTC. After that, a signed 32-bit clock wraps to 1901.
  3. Postgres to_timestamp(1740000000) is seconds. MySQL FROM_UNIXTIME(1740000000) is seconds. JS new Date(1740000000) is milliseconds, so that same number is Jan 1970.
  4. date +%s is seconds. Java System.currentTimeMillis() is milliseconds. Don't copy one into the other.

When it breaks

  • A negative timestamp is before 1970, not an error.
  • Leap seconds are ignored by Unix time. Don't use this to schedule “exactly 23:59:60.”
  • Local vs UTC is the other classic miss. This conversion is UTC unless you say otherwise.

Features

  • Detects 10-digit seconds vs 13-digit milliseconds from the digit length
  • Shows the Y2038 boundary for 32-bit time_t (2038-01-19 03:14:07 UTC)
  • Postgres, MySQL, and Unix date snippets for the same instant
  • ISO 8601 in, Unix out (and the reverse)
  • UTC, local, and relative views of one instant

Common Use Cases

  • Decide if a log value is seconds or milliseconds before you query
  • Convert JWT exp (always seconds) without treating it as JS Date ms
  • Generate to_timestamp / FROM_UNIXTIME SQL for a known instant
  • See whether a 32-bit column will overflow in 2038

Ten digits is seconds. Thirteen is milliseconds.

Ten digits is seconds. Thirteen is milliseconds. Mix them up and you get 1970, or the year 56000, and then you debug the database for an hour.

Paste a timestamp, a date, or now. Read the unit first. If the number is 13 digits, it is not what Postgres to_timestamp wants.

Seconds are 10 digits (until 2286). Milliseconds are 13. Microseconds are 16. If you aren't sure, check the length before you convert. Y2038 is real on 32-bit time_t. 2147483647 is 2038-01-19 03:14:07 UTC. After that, a signed 32-bit clock wraps to 1901.

Postgres to_timestamp(1740000000) is seconds. MySQL FROM_UNIXTIME(1740000000) is seconds. JS new Date(1740000000) is milliseconds, so that same number is Jan 1970. date +%s is seconds. Java System.currentTimeMillis() is milliseconds. Don't copy one into the other.

Examples

Valid - Seconds (10 digits, 2023)
1690000000
Valid - Milliseconds (13 digits, same era)
1690000000000
Valid - Y2038 last 32-bit second
2147483647
Invalid - Seconds fed to JS Date (looks like 1970)
new Date(1690000000)  // 1970-01-20, wrong unit

Frequently Asked Questions

How do I tell seconds from milliseconds?

Ten digits is seconds. Thirteen is milliseconds. Mix them up and you get 1970, or the year 56000, and then you debug the database for an hour. Seconds are 10 digits (until 2286). Milliseconds are 13. Microseconds are 16. If you aren't sure, check the length before you convert.

What is Y2038?

Y2038 is real on 32-bit time_t. 2147483647 is 2038-01-19 03:14:07 UTC. After that, a signed 32-bit clock wraps to 1901.

Is Postgres to_timestamp seconds or milliseconds? What about JS Date?

Postgres to_timestamp(1740000000) is seconds. MySQL FROM_UNIXTIME(1740000000) is seconds. JS new Date(1740000000) is milliseconds, so that same number is Jan 1970. date +%s is seconds. Java System.currentTimeMillis() is milliseconds. Don't copy one into the other. If the number is 13 digits, it is not what Postgres to_timestamp wants.

Is a negative timestamp an error? What about leap seconds?

A negative timestamp is before 1970, not an error. Leap seconds are ignored by Unix time. Don't use this to schedule “exactly 23:59:60.” Local vs UTC is the other classic miss. This conversion is UTC unless you say otherwise.

Common Mistakes

A negative timestamp is before 1970, not an error.
Leap seconds are ignored by Unix time. Don't use this to schedule “exactly 23:59:60.”
Local vs UTC is the other classic miss. This conversion is UTC unless you say otherwise.

Related Tools

JWT Decoder

exp and iat are Unix seconds, not JS milliseconds

Try it

Timezone converter

Same instant in another zone after you have Unix time

Try it

ISO 8601 tools

When the log is 2026-08-27T12:00:00Z instead of a number

Try it

Tips

  • When a log is ambiguous, interpret as both seconds and ms. One of them is a nonsense year.
  • Store UTC in the database. Convert to a zone only at display time.
  • Do not pass JWT exp straight into new Date(exp) without multiplying by 1000.