Unix Timestamp Converter

about this tool

Both directions

Paste a Unix timestamp and read it as a date in any timezone, or enter a date and get the timestamp. The unit — seconds, milliseconds or microseconds — is detected from the number of digits, so pasting a value straight out of a log or a database usually needs no configuration.

Which unit you are looking at

A rough guide by length, for a present-day value:

• 10 digits — seconds. The Unix convention, and what most APIs and databases store.
• 13 digits — milliseconds. JavaScript's Date.now(), and Java.
• 16 digits — microseconds. Common in Python and in tracing systems.

Getting this wrong produces a date in 1970 or in the year 50,000, which is at least obvious. The subtler bug is a comparison between two values in different units, which yields a plausible but wrong duration.

What a Unix timestamp does and does not contain

A timestamp is a count of seconds since 1 January 1970 UTC. It has no timezone — it is a single instant, and the same value renders as a different wall-clock time everywhere in the world. The zone you choose here changes only how it is displayed, never what it means.

That is precisely why timestamps are the right thing to store: they are unambiguous. A stored string like 2024-03-15 14:30:00 with no offset is a recurring source of bugs, because nobody can say later which zone it was written in.

Nor does a Unix timestamp count leap seconds. It assumes every day has exactly 86,400 seconds, which keeps the arithmetic simple and means it is not a true count of elapsed physical seconds.

The same zone confusion is why scheduled jobs misfire at daylight-saving changes; the cron parser shows next run times in a chosen zone.

The 2038 problem

A signed 32-bit integer holding seconds overflows on 19 January 2038, which is the same class of bug as the year 2000 and is still present in older embedded systems, filesystem formats and database columns. Any new column storing a timestamp should be 64-bit. Systems that store a date decades in the future — a mortgage term, a certificate expiry, a pension date — meet it already, not in 2038.

Negative timestamps

Dates before 1970 are negative. They are valid and handled here, though plenty of software rejects them, which is worth remembering if you are storing a date of birth.

For the gap between two timestamps rather than the instants themselves, the duration converter reads 2h30m, PT2H30M and a bare number of seconds, and writes any of them back.

Local

Conversion happens in the page, with no request to a time service.

questions

Is my timestamp in seconds or milliseconds?

For a present-day value, 10 digits is seconds, 13 is milliseconds and 16 is microseconds. The unit is detected from the digit count, so pasting a value straight from a log usually needs no configuration.

Does a Unix timestamp contain a timezone?

No. It is a single instant counted from 1 January 1970 UTC, and it renders as a different wall-clock time in every zone. Choosing a zone here changes only the display, never the value.

Why store timestamps instead of date strings?

Because a timestamp is unambiguous. A stored string like '2024-03-15 14:30:00' with no offset is a recurring source of bugs, since nobody can later say which timezone it was written in.

What is the year 2038 problem?

A signed 32-bit integer holding seconds overflows on 19 January 2038. Older embedded systems, filesystem formats and database columns are still affected, and anything storing a far-future date such as a mortgage term or certificate expiry meets it today.

Can it handle dates before 1970?

Yes, they are negative timestamps and are handled here, though plenty of other software rejects them — worth knowing if you are storing a date of birth.