Timestamp Converter
Translate Unix timestamps to human dates and back.
Part of developer tools.
Seconds, milliseconds, microseconds or nanoseconds, detected for you
A Unix timestamp counts the time elapsed since 1 January 1970 UTC, but the unit depends on where it came from: Go, Python and most databases hand you seconds, while JavaScript’s Date.now() and Java’s currentTimeMillis() hand you milliseconds. Postgres and tracing tools often use microseconds, and Go’s UnixNano() and structured logs use nanoseconds. The unit is picked by order of magnitude: below 10¹² it is read as seconds, below 10¹⁵ as milliseconds, below 10¹⁸ as microseconds, and as nanoseconds above. Each line sits in 2001 for the larger unit and past the year 33658 for the smaller one, so the guess is never genuinely ambiguous — and the unit retained is shown under the result.
The timezone trap in date strings
Paste 2026-08-07 and you get midnight UTC; paste 2026-08-07 09:30 and the browser reads it in your local zone instead. That asymmetry is in the ECMAScript specification, not a quirk of this page, and it is behind a large share of off-by-one-day bugs. Adding an explicit Z or a +02:00 offset removes the ambiguity entirely.
Why UTC and your local time are both shown
A timestamp itself has no timezone — it is a single instant, and UTC versus local is only a question of how you render it. Storing and transmitting instants in UTC and converting at the point of display is the convention that avoids trouble, especially around daylight saving transitions where a local wall-clock time can occur twice or not at all.
The 2038 problem
Systems that store Unix time in a signed 32-bit integer overflow on 19 January 2038, wrapping to 1901. Modern platforms use 64-bit values and are unaffected, but the limit still surfaces in older embedded devices and in database columns typed too narrowly. If you are choosing a column type today, make it 64-bit.