Unix Timestamp Converter

About Unix Timestamp Converter

A Unix timestamp is the number of seconds since 1970-01-01 00:00:00 UTC. It's what you find in server logs, database columns and API fields like created_at: a bare integer such as 1789000000. This converter turns that integer into a readable date and a date back into the integer.

The number carries no time zone. 1790035200 is 9:00 a.m. on September 22, 2026 in Seoul, midnight UTC, and 8:00 p.m. the previous evening in New York during daylight time. Nearly every mistake with timestamps comes from two places: the unit (seconds or milliseconds) and the zone used to display it.

Ten digits or thirteen: seconds versus milliseconds

Classic Unix time is in seconds, but JavaScript's Date.now() and Java's System.currentTimeMillis() return milliseconds, so the same instant shows up as 1789000000 in a Postgres column and 1789000000000 in a browser log. Read a millisecond value as seconds and you get a date around the year 58,000; read a seconds value as milliseconds and you land on January 21, 1970. If a conversion comes out near 1970 or absurdly far in the future, check the unit before anything else.

The tool decides the unit from the number of digits in the integer part. Right now a timestamp has 10 digits in seconds, 13 in milliseconds, 16 in microseconds and 19 in nanoseconds, so up to 11 digits is read as seconds, 12 to 14 as milliseconds, 15 to 17 as microseconds and 18 or 19 as nanoseconds. The ISO 8601 converter uses the same rule. Second-based timestamps became 10 digits at 1000000000 (September 9, 2001) and stay 10 digits until the year 2286, so the rule holds for any value you're likely to meet today. A value with a decimal point, like 1789000000.5, is read as seconds, and results are shown truncated to whole seconds.

Some systems use yet other units: Python's time.time() gives fractional seconds, and Go and many tracing tools use nanoseconds (19 digits). You can paste a nanosecond or microsecond value as is; the tool detects it and converts to milliseconds.

The Year 2038 problem, concretely

The largest signed 32-bit integer is 2^31 − 1 = 2147483647. Convert it and you get 2038-01-19T03:14:07Z. One second later, a 32-bit counter overflows to −2147483648, which decodes to December 13, 1901. That's the whole Y2038 problem.

Modern 64-bit operating systems and languages use a 64-bit time_t and are fine. The risk sits in older embedded devices, file formats with 4-byte time fields, and database columns declared as 32-bit integers. MySQL's TIMESTAMP type, for instance, is documented with an upper bound of 2038-01-19 03:14:07 UTC. Anything that stores future dates, such as a 15-year mortgage schedule or a long-lived certificate, is already crossing that line today, not in 2038.

Leap seconds don't exist in Unix time

POSIX defines “seconds since the Epoch” with every day treated as exactly 86,400 seconds. UTC has had 27 leap seconds inserted since 1972, and none of them are counted. The most recent, 2016-12-31T23:59:60Z, simply has no Unix timestamp: systems either repeated a second or, like Google and AWS, “smeared” the extra second across the surrounding hours.

The practical consequence is that subtracting two timestamps gives elapsed time that can be off from true SI seconds by up to 27 seconds over long spans. For logs and billing that's irrelevant; for satellite navigation or physics, people use TAI or GPS time instead. The General Conference on Weights and Measures resolved in 2022 to stop adding leap seconds by 2035, which will end the discrepancy growing. This tool, like JavaScript, rejects 23:59:60 as input.

Displaying in other zones

The date-and-time input is interpreted in your computer's time zone, as reported by the browser. If you're in Chicago and want the timestamp for 9:00 a.m. in Tokyo, don't type 09:00 here; either convert to UTC first or use the ISO 8601 converter, where you can attach an explicit offset like +09:00.

Korea (KST) and Japan (JST) are both UTC+9 year-round with no daylight saving time. U.S. zones shift by an hour twice a year, so the gap between New York and Seoul is 13 hours in summer and 14 in winter. A daily report cut at UTC midnight splits an Asian business day at 9 a.m. local time, a common source of “missing” orders in dashboards.

Worked examples

How to use it

1. Paste a timestamp; the unit is detected and the UTC, local and relative times appear.
2. To go the other way, pick a date and time; you get both seconds and milliseconds.
3. Use the Now button to grab the current timestamp.

Frequently asked questions