⌛Unix Timestamp Converter

If a date in your application is showing as January 1970 or some year in the fifty-thousands, you have a seconds-versus-milliseconds problem and nothing else.

Unix timestamps count seconds. JavaScript counts milliseconds. Date.now() returns 1757203200000 where PHP time() returns 1757203200, and passing one where the other is expected is comfortably the most common date bug in web development.

The quick check: ten digits is seconds, thirteen is milliseconds. In JavaScript, Math.floor(Date.now() / 1000) gives you the Unix value.

Why the format exists

It counts seconds since midnight UTC on 1 January 1970, ignoring leap seconds. Because it is a single integer with no time zone attached, it is unambiguous, sorts naturally, and subtracts cleanly. That is why databases, APIs and log files use it rather than formatted dates — every formatted date carries an implicit question about whose clock it refers to.

The hour that goes missing

If a converted time is out by exactly one hour, it is daylight saving. If it is out by a whole number of hours, it is a time zone. The timestamp itself is always UTC; whatever displays it is applying an offset, and one of the two systems involved has the wrong one.

What not to store as a timestamp

A moment in time — when something happened — is exactly what this format is for.

A future appointment in a particular place is not. Store the local time and the zone separately. Governments change their offsets with a few months notice, and a meeting stored as a UTC instant silently moves to the wrong local time when they do. This has broken real scheduling systems more than once.

2038

Signed 32-bit timestamps overflow on 19 January 2038. Modern systems use 64-bit values, but the problem still surfaces in embedded devices and in old database columns that nobody has looked at.