Unix Time Converter

Convert Unix epoch values at any precision, with hex output and a year-2038 overflow check.

ConvertersRuns in your browserFree, no sign-up

Options

Numeric input is in

10 digits is almost always seconds, 13 is milliseconds.

Unix time or date

Conversions

Output appears here as you type.

Ctrl + Enter to run

About the Unix Time Converter

Unix time counts seconds from 1970-01-01 UTC, which makes it a single number that is unambiguous across time zones and easy to compare and sort. That is why logs, databases and APIs store it in preference to formatted dates.

The value to watch is the unit. JavaScript's `Date.now()` and most JVM APIs return milliseconds, while the Unix convention and most command-line tools use seconds. Passing one where the other is expected produces a date that is either just after 1970 or thousands of years away.

Frequently asked questions

What is the year 2038 problem?

Unix time stored in a signed 32-bit integer overflows at 03:14:07 UTC on 19 January 2038 — the counter wraps to a negative number and the date jumps to 1901. Any system still using a 32-bit time_t, including plenty of embedded devices and some database columns, is affected. This tool flags timestamps beyond that boundary.

Why do some APIs use milliseconds and others seconds?

Convention, mostly by language. C, Python, PHP, Go and Unix tools default to seconds; JavaScript's Date.now() and Java's currentTimeMillis() return milliseconds. JWT timestamps are always seconds per RFC 7519. Mixing the two is one of the most common date bugs in cross-language systems.

Does Unix time account for leap seconds?

No, and this is a deliberate simplification in the standard. Unix time assumes every day is exactly 86,400 seconds, so a leap second is either repeated or skipped depending on the system. It is not a monotonic count of real elapsed seconds — use a monotonic clock if you are measuring durations.