Unix timestamp converter

Unix time in one paragraph

Unix time counts the seconds elapsed since 00:00:00 UTC on 1 January 1970, a moment known as the epoch. It ignores time zones and daylight saving entirely: at any given instant the Unix time is the same number everywhere on Earth. That makes it the natural format for storing and comparing moments in databases, log files, JWT exp and iat claims, file modification times, API responses and cron-like schedulers. The catch is that 1700000000 means nothing to a human, which is what this converter is for. For the record, it is 14 November 2023, 22:13:20 UTC.

Seconds, milliseconds and longer numbers

Different systems count in different units:

• Seconds, 10 digits for current dates: Unix and Linux tools, PHP time(), Python time.time() (with a fractional part), most SQL databases, JWTs.
• Milliseconds, 13 digits: JavaScript Date.now(), Java System.currentTimeMillis(), many JSON APIs and analytics events.
• Microseconds, 16 digits, and nanoseconds, 19 digits: some databases, Go, high-resolution tracing tools.

The tool decides the unit by size. Any whole number with an absolute value below 100,000,000,000 is read as seconds, up to 100,000,000,000,000 (14 digits) as milliseconds, below 10^17 as microseconds and anything larger as nanoseconds. Those thresholds work for every realistic case: as seconds the first would be the year 5138, as milliseconds early March 1973.

Microsecond and nanosecond values are cut to millisecond precision, since that is all the outputs show. Fractional input such as 1700000000.5 is not accepted, so drop the decimal part first.

Negative numbers work and give dates before 1970: -86400 is 31 December 1969.

Reading the six outputs

• Unix seconds and Unix milliseconds: the same instant in both units. Milliseconds are kept when you paste a date string with a time part like .250; the seconds value is rounded down.
• ISO 8601: for example 2023-11-14T22:13:20.000Z. Always in UTC, marked by the Z, with millisecond precision. This is the safest format for APIs and JSON, because it sorts correctly as text and every language parses it.
• UTC: the HTTP date style, Tue, 14 Nov 2023 22:13:20 GMT, used in Expires, Last-Modified and cookie headers.
• Your time zone: day/month/year with a 24-hour clock, followed by the time zone abbreviation (or a GMT offset where none exists) and the zone name your browser reports, such as Europe/Berlin. Daylight saving is applied for that date, not today's offset.
• Relative: wording such as "yesterday", "in 3 days" or "2 years ago". It is approximate by design: months are averaged at about 30.4 days, and the value updates while the page is open.

Converting a date into a timestamp

You can paste a date instead of a number. ISO 8601 strings are the most reliable input, and the time zone rules are worth knowing because they cause most off-by-hours mistakes:

• 2024-05-01T12:00:00Z and 2024-05-01T12:00:00+02:00 carry their own offset and are unambiguous.
• 2024-05-01 with no time is treated as midnight UTC.
• 2024-05-01T12:00 and 2024-05-01 12:00, a date with a time but no offset, are treated as your local time.

So if you are in Berlin in summer, 2024-05-01 and 2024-05-01 00:00 differ by two hours. When converting for a server or an API, add Z or an explicit offset to remove the guesswork.

Other formats, like May 1, 2024 12:00, depend on the browser's date parser and may behave differently between Chrome, Firefox and Safari. Formats with the day first, such as 01/05/2024, are read as month first in the US style or rejected, so avoid them.

Pitfalls worth knowing

• Leap seconds. Unix time pretends every day has exactly 86,400 seconds. The 27 leap seconds added since 1972 are not counted, which only matters for precise scientific timing.
• The year 2038 problem. Systems that store Unix time as a signed 32-bit integer overflow at 2147483647, which is 19 January 2038, 03:14:07 UTC. Paste that number to see it. Modern 64-bit systems are not affected, but old embedded devices and file formats can be.
• Clock skew. If a JWT is rejected as "not yet valid" or "expired", compare its iat and exp with the live Current Unix time at the top of the page. A difference of a few minutes points to a wrong clock rather than a bad token.

To read a token's claims, decode its middle part with the Base64 tool and tidy the JSON in the JSON formatter. Conversions run in your browser using its own clock and time zone settings.