Unix Timestamp Converter

How to use the timestamp converter

The top of the tool shows the current Unix time in seconds and milliseconds, updated every second. Press Pause to freeze it while you copy a value, and Convert current time to send it to the converter below.

1. Timestamp to date: paste a number such as 1700000000. The unit is detected from the number of digits, or you can force seconds, milliseconds, microseconds or nanoseconds. You get the date in UTC, in your local time zone, as ISO 8601, as an RFC 2822 email date and as a relative time like "3 hours ago".
2. Date to timestamp: pick a date and time and choose whether it means local time or UTC, or paste a string such as 2024-03-01T12:00:00+01:00. The result appears in seconds and milliseconds.

Everything is calculated locally with your browser's clock and time zone database. Nothing is sent anywhere.

Worked example

In the other direction, 2024-03-01 12:00:00 interpreted as UTC is 1709294400 seconds, and the same wall-clock time in Berlin (UTC+01:00 in winter) is 1709290800.

What a Unix timestamp is

Unix time counts the seconds that have passed since the epoch, 1 January 1970 at 00:00:00 UTC. It has no time zone: the same instant has the same timestamp everywhere, and the time zone only matters when you display it. Leap seconds are not counted, so every day is exactly 86,400 seconds long.

Different systems use different units. Unix shells, PHP and most databases use seconds. JavaScript's Date.now() and Java's System.currentTimeMillis() return milliseconds. Python's time.time_ns() and some logging systems use nanoseconds. Auto-detection looks at the magnitude: values with up to 11 digits are read as seconds, and each further three digits switch to milliseconds, microseconds and nanoseconds. For dates between about 1973 and 5138 this guess is always right.

The famous year 2038 problem comes from storing seconds in a signed 32-bit integer. Its maximum value, 2147483647, is reached on 19 January 2038 at 03:14:07 UTC. Systems that use 64-bit integers, like JavaScript and modern operating systems, are not affected.

Common mistakes

• Mixing up seconds and milliseconds. A millisecond value read as seconds lands tens of thousands of years in the future, and seconds read as milliseconds land in January 1970. If a date looks absurd, check the unit.
• Forgetting the time zone of the input. 2024-03-01T12:00 without an offset is ambiguous. This tool applies the time zone you select; add Z or an offset like +01:00 to make a string unambiguous.
• Assuming local time is stored. The timestamp is the same for every user. Only the formatted date changes with the viewer's time zone and daylight saving time.
• Losing precision in JavaScript. Numbers above 2^53 are not exact. Nanosecond timestamps are parsed here as big integers, but dates are shown with millisecond precision.

Need to generate IDs that embed time? See the UUID generator. Inspecting the exp and iat claims of a token? The JWT decoder shows them as Unix timestamps too.