How to Convert a Unix Timestamp

If you work with APIs, databases, or log files, you will inevitably encounter a number like 1714502400 and need to know what date it represents. The Unix timestamp converter translates these values into human-readable dates and back again, saving you from mental arithmetic and off-by-one timezone errors.

Understanding epoch time

A Unix timestamp is the number of seconds that have elapsed since January 1, 1970, 00:00:00 UTC, a moment known as the Unix epoch. This single integer representation makes dates easy to store, compare, and transmit. Sorting timestamps is just sorting numbers. Calculating the duration between two events is a simple subtraction. There is no ambiguity about date formats like 01/02/03, and no implicit timezone to misinterpret.

Many systems use millisecond timestamps (13 digits instead of 10). JavaScript’s Date.now() returns milliseconds, while Python’s time.time() returns seconds with a decimal. When a conversion looks wildly wrong, such as a date in the year 52000, you have almost certainly passed a millisecond timestamp to something expecting seconds, or vice versa.

Timezone handling is where most bugs live. A Unix timestamp is always UTC by definition. When you convert it to a local date, the result depends on the timezone of the machine or library doing the conversion. A timestamp that represents midnight UTC is still the previous evening in New York. Always be explicit about which timezone you are displaying and never assume “local time” is the same for every user.

The Y2038 problem is the Unix equivalent of Y2K. Systems that store timestamps as a 32-bit signed integer will overflow on January 19, 2038, wrapping around to a date in December 1901. Most modern systems use 64-bit integers, which pushes the overflow date billions of years into the future, but legacy embedded systems and some databases still use 32-bit timestamps.

Tips and best practices

• Always store timestamps in UTC. Convert to local time only at the display layer. This avoids confusion when users, servers, or databases are in different timezones.
• Know your precision. Check whether your system uses seconds, milliseconds, or microseconds. Mixing them up produces dates that are off by orders of magnitude.
• Use ISO 8601 for human interchange. When you need a readable date format in APIs or logs, 2026-03-21T14:30:00Z is unambiguous. Reserve Unix timestamps for storage and computation.
• Watch out for negative timestamps. Dates before the epoch (January 1, 1970) are represented as negative numbers. Not every library handles negative timestamps correctly.

Troubleshooting

• Converted date is decades off: You are likely confusing seconds and milliseconds. A 13-digit number is milliseconds; divide by 1000 to get seconds before converting.
• Date is correct but the time is wrong: The timestamp is UTC, but your system is displaying it in local time (or vice versa). Use the date difference calculator to verify offsets if you suspect a timezone issue.
• Database returns 0000-00-00 or null: Some databases cannot store timestamps outside the 32-bit range. If you are working with dates before 1970 or after 2038, make sure your column type supports the range you need.