Unix Timestamp to Date and Back

About the tool: Unix timestamps and dates

Databases, logs and API responses store time as a number, and there is no way to read it out loud. This tool turns such a number into a date you can understand, and back again — the two fields are linked, so you may edit either one. There are no third-party ads and no sign-up.

Everything is computed in your browser — the value is never sent to a server or stored anywhere.

Key benefits of the tool:

• The unit is detected on its own: seconds, milliseconds, microseconds or nanoseconds are recognised by their order of magnitude. If the guess is wrong, you can set the unit by hand.

• Any time zone: not only yours and UTC, but the whole IANA list. That is what matters when the server lives in one zone and you live in another.

• The current value is always in sight: a live timestamp ticks at the top in seconds and milliseconds, and copies with a single click.

What a Unix timestamp is

It is the number of seconds that have passed since 1 January 1970, 00:00 UTC — the moment known as the epoch. The number depends neither on the time zone nor on daylight saving, which makes it convenient to store: the same instant in Ukraine and in California is written identically, and only the ways of displaying it diverge.

Seconds or milliseconds

A standard Unix timestamp counts seconds, and that is exactly how PHP, Python and databases hand it over. But JavaScript in Date.now() returns milliseconds, so the number there is a thousand times bigger. This is the most common reason a date suddenly lands in 1970 or, the other way round, in the distant future.

Telling them apart is easy by length: in seconds a modern date has 10 digits, in milliseconds — 13. Microseconds give 16 digits, nanoseconds — 19; you meet such values in Python and in databases like ClickHouse.

About time zones

The timestamp itself has no zone. A zone appears only when the number is turned into a date, and that is where most mistakes come from.

• A server usually lives in UTC: if the time in your logs is several hours off your own clock, that is almost always the reason.

• Daylight saving shifts the offset: for Kyiv it is +02:00 in winter and +03:00 in summer. The tool accounts for this per date rather than taking the current offset.

• The same instant has different spellings: changing the zone here does not change the moment, only the way it looks.

A few practical tips

• Compare moments as numbers, not as strings: two different spellings may mean the same instant, and the other way round.

• Store in UTC, display in the user time zone: this rule saves you from most time-related trouble in applications.

• Beware of the year 2038: in a signed 32-bit integer the timestamp overflows on 19 January 2038. If time is kept in an int32 anywhere in your system, it is worth checking early.

• Negative values are valid too: they stand for dates before 1970, and the tool accepts them.