Unix Timestamp Converter

What a Unix timestamp is

A Unix timestamp (also called epoch time or POSIX time) is the number of seconds that have elapsed since 00:00:00 UTC on 1 January 1970, not counting leap seconds. It is the most common way computers store and exchange points in time because it is a single integer that does not depend on time zones, calendars or locale formats. Databases, log files, JWT tokens, APIs and operating systems all use it, which is why developers constantly need to translate between a raw number like 1700000000 and a date a human can read.

Different systems use different precision. Unix and most databases store seconds (10 digits today). JavaScript's Date.now() and Java's System.currentTimeMillis() return milliseconds (13 digits). Some logging systems and Go's time package expose microseconds (16 digits) or nanoseconds (19 digits). This converter detects the unit from the number of digits automatically, so you can paste any of them without choosing a format.

How to use this converter

The live clock at the top shows the current Unix timestamp in seconds and updates every second; click Copy to grab it or Use now to load it into the converter. Paste a timestamp in the input box and the table fills in instantly: seconds, milliseconds, ISO 8601 (the standard used by most APIs), RFC 1123 UTC string, the date and time in your local time zone with its name, a relative description such as 'in 3 days' or '2 hours ago', the weekday, the day of the year and the ISO week number.

The converter also works in the other direction. Type a date such as 2025-03-01, 2025-03-01T14:30:00Z, or March 1 2025 14:30 and it is parsed with your browser's date engine and converted to epoch seconds and milliseconds. Dates without an explicit zone are interpreted in your local time zone, exactly as JavaScript does.

Time zones, ISO 8601 and common pitfalls

A timestamp itself has no time zone; only its rendering does. The same value 1700000000 is 22:13 in London and 06:13 the next day in Shanghai. When two systems disagree by exactly a few hours, a time zone mix-up is almost always the cause. Prefer exchanging ISO 8601 strings with an explicit Z or offset (2024-11-14T22:13:20Z) or raw epoch numbers rather than local date strings. Another classic bug is mixing seconds and milliseconds: a date in the year 55000 or in 1970 usually means a unit mismatch, and the 'detected as' note under the input tells you which unit was assumed. Finally, remember the 32-bit limit: systems storing seconds in a signed 32-bit integer overflow on 19 January 2038.

Background: why 1970?

The Unix epoch was chosen by the Unix developers at Bell Labs in the early 1970s; the first edition counted 60ths of a second from 1971 and overflowed within months, so it was changed to whole seconds from 1 January 1970 — a round date safely in the recent past. Because it ignores leap seconds, every Unix day is exactly 86,400 seconds, which makes arithmetic trivial and is why the format spread from Unix to every database, programming language and network protocol. The Year 2038 problem, when signed 32-bit counters wrap, is the direct legacy of that early design; modern systems store 64-bit values and are safe for the next 292 billion years.

Where it is used

Timestamps are the exp, iat and nbf claims inside a JWT token, the created_at columns in almost every database, the first field of most log lines, HTTP cache headers, cron and scheduling systems, blockchain block headers, file system metadata (mtime), and the ETag/Last-Modified logic that decides whether a CDN can reuse a cached page. When a support ticket says 'the export failed at 1718000000', this converter is how you turn it into a time on a human calendar; when writing tests, converting a fixed date into epoch seconds gives you a stable, time-zone-independent value to assert against. Structured data on this site, and in any JSON API you build, should use ISO 8601 strings for readability and epoch integers for arithmetic.

Frequently asked questions