Unix Timestamp Converter

A Unix timestamp — also called epoch time — is the number of seconds that have passed since 00:00:00 UTC on 1 January 1970. That moment is the Unix epoch. Because it is a single integer carrying no timezone, no locale and no formatting, it is the cheapest way for a machine to name an exact instant.

Timestamps are stored in UTC so that logs, APIs and databases stay comparable across servers and time zones. The number itself is neutral; turning it into something a person reads — local time, daylight saving, an ISO 8601 string — happens at the edge, which is what this page does for you.

The panel above converts in both directions at once. If you only need one, the timestamp to date converter and the date to timestamp converter each do a single job with more output formats, the current unix timestamp ticks on its own page, and the Discord timestamp generator turns an instant into a tag that renders in each reader’s own zone.

This is where most timestamp confusion starts. C, Python, Go, PostgreSQL and most Unix tooling count whole seconds, so a current timestamp is 10 digits. JavaScript, Java and many logging pipelines count milliseconds, so the same instant is 13 digits.

Read a millisecond value as seconds and your date lands tens of thousands of years in the future. Read seconds as milliseconds and you get 1970. The converter checks the digit count before converting and labels the unit it detected, so you can paste either one without thinking about it.

Microseconds and nanoseconds are handled the same way. A present-day timestamp is 10 digits in seconds, 13 in milliseconds, 16 in microseconds and 19 in nanoseconds, so the timestamp to date converter reads all four and tells you which it used — useful when a value comes out of a Go service or a tracing pipeline rather than a database.

Because Unix time counts a flat 86,400 seconds per day, these figures are exact arithmetic rather than calendar approximations — useful when you need to add an offset to a timestamp by hand.

There is deliberately no row for “1 month”: calendar months run from 28 to 31 days, so any single figure for one would be wrong most of the time. Add months with a date library or with the date to timestamp converter instead of multiplying seconds.

A few reference points worth recognising when a value looks wrong at a glance.

Negative values are valid and describe instants before 1970: −86,400 is 31 December 1969. You can check any of these in the timestamp to date converter.

Systems that store Unix time in a signed 32-bit integer can count no higher than 2147483647 seconds, which is 19 January 2038 at 03:14:07 UTC. One second later the value overflows and wraps to a negative number, reading as December 1901.

The fix is a 64-bit time field, which most current systems already use. Embedded devices, old file formats and database columns typed as a 32-bit integer are where it still bites. This converter uses 64-bit floating point numbers, so you can convert a timestamp past the 2038 limit and get the correct date back.