Unix Timestamp Converter

Convert between Unix timestamps (epoch seconds or milliseconds) and human-readable dates. Supports multiple timezones, an instant "now" fill, and relative time display for developers.

Unix Timestamp Basics

A Unix timestamp represents a date and time as the number of seconds elapsed since 00:00:00 UTC on January 1, 1970 (the Unix epoch). Below is a table of well-known timestamp values and the dates they represent.

Timestamp (seconds) UTC date & time Note
0 1970-01-01T00:00:00Z The Unix epoch (the starting point of all timestamps)
1000000000 2001-09-09T01:46:40Z The moment the timestamp reached one billion seconds (the "Unix billennium")
1234567890 2009-02-13T23:31:30Z A value that became a minor curiosity for containing the digits 1 through 9 in sequence
2147483647 2038-01-19T03:14:07Z The Year 2038 problem: the maximum value of a signed 32-bit integer (it overflows one second later)

Usage Tips

  • A 10-digit value is usually in seconds, while a 13-digit value is usually in milliseconds. Selecting "Auto-detect" infers the unit from the digit count for you.
  • Paste a timestamp straight from a server log or API response to check its equivalent time across several timezones at once.
  • When converting a date to a timestamp, make sure you explicitly select which timezone the entered date and time belongs to.
  • The ISO 8601 (UTC) format can be parsed directly by most programming languages and databases, making it a handy reference when searching logs or designing an API.
  • Click "Fill current time" to instantly populate the field with the current time from the browser's Date.now().

Frequently Asked Questions

A Unix timestamp (epoch time) expresses a date and time as the number of seconds elapsed since 00:00:00 UTC on January 1, 1970 (the Unix epoch). Because it represents a moment in time as a single, timezone-independent number, it is widely used as a standard way to exchange dates and times between computers, such as in server logs, databases, and APIs.

The Year 2038 problem refers to a bug in systems that store Unix timestamps as signed 32-bit integers: one second after 03:14:07 UTC on January 19, 2038 (the maximum value, 2,147,483,647), the value overflows and the represented date wraps back to around 1901. Most modern systems use 64-bit integers and are unaffected, but embedded devices and legacy systems can still be at risk.

A timestamp representing the current era (the 2020s to 2030s) will generally have about 10 digits if it is in seconds, or about 13 digits if it is in milliseconds. This tool's "Auto-detect" mode uses that digit-count difference to guess the unit, but checking the original data's specification or API documentation is the most reliable way to be sure.

There is no single, definitively documented reason, but it is generally attributed to Unix having been developed around 1969-1970 and to the round, convenient year fitting the memory constraints of computers at the time. This date became known as the "Unix epoch" and has since become a de facto standard followed by nearly every programming language and operating system.

A negative value represents a date and time before January 1, 1970. For example, the timestamp -86400 corresponds to 00:00:00 UTC on December 31, 1969. Systems that handle historical dates or birthdates earlier than 1970 sometimes make use of negative timestamps.
ツールくん

Side Note — Why do computers count time in seconds?

Humans express dates and times as a combination of year, month, day, and time of day, such as "July 12, 2026, 5:08 PM." For a computer, however, this format is inconvenient: it has to account for complex rules like leap years, timezones, and daylight saving time, and even computing the gap between two dates becomes a cumbersome operation. The solution devised was to represent time as a single number: the number of seconds elapsed since some reference moment. This is exactly what a Unix timestamp does.

The biggest advantage of representing time as a single integer is that comparing and computing differences between dates reduces to simple arithmetic. Finding "how many seconds apart are these two events" is just a matter of subtracting one timestamp from another, with no need to worry about leap years or varying month lengths. Thanks to this simplicity, the format was adopted not only by Unix-like systems but also by Windows, databases, and the internal representations of many programming languages, making it a de facto global standard.

On the other hand, this design of a single, timezone-independent number means that timezone conversion only becomes necessary once a human needs to read the value. The very same timestamp can look like the middle of the night in Tokyo and the previous afternoon in New York, depending on which timezone it is displayed in. Many of the confusing "the time is off" bugs encountered while investigating logs or debugging API integrations trace back to exactly this kind of overlooked timezone conversion.