Epoch & Unix Timestamp Converter

Unix time is defined in seconds. JavaScript's Date.now returns milliseconds. A 10-digit number is seconds, a 13-digit number is milliseconds - mixing them is the single most common date bug there is.

A signed 32-bit timestamp overflows on 19 January 2038. Anything storing time in a 32-bit integer breaks then. Use 64-bit integers or a native timestamp type.

No. It assumes every day is exactly 86,400 seconds, so it drifts from actual astronomical time. That is deliberate - it keeps the arithmetic simple.

Almost always a timezone issue. A date with no time component is midnight UTC, which is the previous day in any negative offset. Store and compare in UTC.

Count the digits. Ten digits is seconds and lands in the present; thirteen is milliseconds. A ten-digit value read as milliseconds gives a date in 1970, which is the classic symptom.

It increments every second. Get it with Math.floor(Date.now()/1000) in JavaScript, time.time() in Python, or date +%s in a shell.

Timezone. A Unix timestamp is always UTC; the date you see depends on the zone used to format it. A midnight UTC timestamp is the previous evening in the Americas.

Store an instant as timestamptz in Postgres, which is a timestamp with the zone handled correctly. Store a calendar date with no time - a birthday, an invoice date - as a plain date, never as an epoch.