Unix Timestamp Converter

Seconds or milliseconds?

Detected automatically by length. Ten digits is seconds — the Unix convention used by date +%s, most databases and most APIs. Thirteen digits is milliseconds, which is what JavaScript's Date.now() returns and what Java, Kotlin and most JVM code uses.

Mixing the two is the single most common timestamp bug. Treating milliseconds as seconds puts you roughly fifty thousand years in the future; treating seconds as milliseconds puts you in January 1970. Both are usually obvious once you see the date, which is why converting is the fastest way to diagnose it.

The 2038 problem

A signed 32-bit integer runs out at 2147483647 — 03:14:07 UTC on 19 January 2038. Systems still storing time in a signed 32-bit value will overflow to 1901. Try that example above.

This is not purely historical. Embedded devices, older industrial controllers, some access-control panels and plenty of firmware that nobody plans to update are all still 32-bit. If you specify equipment with a fifteen-year service life today, 2038 is inside it.

Store UTC, display local

The rule that prevents most date bugs. Store the instant in UTC, convert to the viewer's timezone only at the point of display. Storing local time means every reader has to know which timezone was meant, and a DST transition makes some values genuinely ambiguous — 1:30 a.m. happens twice on the fall-back date.

ISO 8601 with an explicit offset (2026-08-26T14:30:00Z) is the right wire format. A bare 2026-08-26 14:30:00 with no offset is an invitation to be misread.

Leap seconds, briefly

Unix time deliberately ignores them: every day is exactly 86,400 seconds. That makes the arithmetic simple and means Unix time is not quite the same as elapsed physical time — the difference is currently 27 seconds against TAI. It matters for precision timing and almost never for anything else.