What the Unix timestamp converter does
A Unix timestamp counts the time since 1970-01-01T00:00:00Z, the Unix epoch. The converter turns a timestamp into its date in every common form, and a date into its timestamp, in seconds, milliseconds, microseconds or nanoseconds. It works out the unit from the number of digits, keeps every digit you give it, shows the date in any time zone, and tells you when a local time falls into a daylight saving change instead of quietly picking one. It parses dates by its own strict rules, so the result is the same in every browser.
How to convert a timestamp
- Paste a timestamp into Timestamp to date, such as
1700000000from a log or1700000000123from JavaScript. The Unit line says how it was read. - Choose a Time zone to see the date there as well; Local is your browser's zone.
- To go the other way, type a date into Date to timestamp, like
2024-02-29T12:00:00+03:00. Without Z or an offset, it is read in the chosen time zone. - Copy any value with the button beside it. Current time shows the timestamp now, in seconds and milliseconds.
Examples
Input
1735689600
Output
Unit: seconds (10 digits)
ISO 8601 (UTC): 2025-01-01T00:00:00Z
America/New_York: 2024-12-31T19:00:00-05:00
RFC 2822: Wed, 01 Jan 2025 00:00:00 +0000
HTTP-date: Wed, 01 Jan 2025 00:00:00 GMT
Milliseconds: 1735689600000
Input
2026-03-08T02:30
Output
Read as: 2026-03-08T03:30:00-04:00 (America/New_York)
Seconds: 1772955000
Milliseconds: 1772955000000
ISO 8601 (UTC): 2026-03-08T07:30:00Z
Input
2025-02-29T10:00:00Z
Problem reported
February 2025 has 28 days. Write it like 2024-02-29, 2024-02-29T12:00 or 2024-02-29T12:00:00.5+03:00. (TIME_INVALID_DATE)
Timestamps often arrive inside JSON, as an exp claim or a created_at field. The JSON Formatter lays out such a response so you can find them, and the JSON Viewer copies a value with its path.
Seconds, milliseconds, microseconds and nanoseconds
Unix time itself is in seconds, but programs count in different units. date +%s, PHP's time(), C's time_t and most APIs use seconds; Python's time.time() adds a fraction. JavaScript's Date.now() and Java's System.currentTimeMillis() return milliseconds. Go offers all four through Unix(), UnixMilli(), UnixMicro() and UnixNano(), Python's time.time_ns() and InfluxDB use nanoseconds, and PostgreSQL stores timestamps to the microsecond.
From September 2001 to November 2286, a timestamp in seconds has 10 digits, in milliseconds 13, in microseconds 16 and in nanoseconds 19. That is how Unit: Auto tells them apart: up to 11 digits it reads seconds, up to 14 milliseconds, up to 17 microseconds, and nanoseconds above. A value below 100,000,000 is the one real doubt, since it could be seconds before 1973 or milliseconds on the first day of 1970, so the converter reads it as seconds and shows the other reading.
The digits are never rounded: a nanosecond timestamp keeps all nine of its fraction digits, which a JavaScript number cannot hold, and the values in the other units are the same number with the decimal point moved.
Time zones and daylight saving time
A timestamp names the same moment everywhere; a time zone only changes how that moment is written. 1700000000 is 22:13 in UTC and 01:13 the next day in Istanbul. An offset like +03:00 describes one moment, while a zone name from the IANA time zone database (opens in a new tab), like Europe/Berlin, carries the zone's whole history: its daylight saving rules and every change of its offset. Some zones are not whole hours from UTC: Nepal is at +05:45, the Chatham Islands at +12:45, and Lord Howe Island moves its clocks by 30 minutes.
Daylight saving time makes some local times ambiguous. When the clocks go forward, an hour of local time never happens: in Berlin, 02:30 does not exist on the last Sunday of March. The converter then moves the time forward by the jump and says so. When the clocks go back, an hour happens twice: 02:30 on the last Sunday of October is first at +02:00, then at +01:00. The converter uses the earlier one and shows the later one too. A date with Z or an offset is never ambiguous, because it names its moment.
ISO 8601, RFC 2822 and HTTP dates
RFC 3339 (opens in a new tab), the internet's profile of ISO 8601, writes 2024-02-29T09:00:00Z: the parts from largest to smallest, so the text sorts in time order, with Z or an offset at the end. It is the form for JSON, logs and APIs. Email headers use the older form of RFC 5322 (opens in a new tab), which replaced RFC 2822: Thu, 29 Feb 2024 09:00:00 +0000. HTTP's Date, Last-Modified and Expires headers use its fixed variant, the IMF-fixdate of RFC 9110 (opens in a new tab), always in GMT.
The converter reads only ISO 8601 dates, and checks each part: a month has the days it has, hours go to 23 and seconds to 59. JavaScript's own Date is less strict. It reads 2024-02-29 as midnight UTC but 2024-02-29T00:00 as local midnight, and some browsers roll 2023-02-30 over into March. Here both forms are read in the chosen time zone, and a day that does not exist is an error.
The year 2038 problem
Many systems store Unix time as a signed 32-bit integer, the classic time_t. Its largest value, 2147483647, is 2038-01-19T03:14:07Z. One second later the number wraps around to its smallest value, which reads as 1901-12-13T20:45:52Z. 64-bit systems use a 64-bit time_t, and Linux has offered one on 32-bit machines since 2020, but old embedded devices, file formats and database columns still carry 32-bit fields: MySQL's TIMESTAMP type, for one, ends at that same second. The converter notes when a time falls outside the 32-bit range, so you can check whether the system that stores it will cope.
Dates before 1970
Negative timestamps count back from the epoch: -1 is 1969-12-31T23:59:59Z, and the first Moon landing, 1969-07-20T20:17:40Z, is -14182940. Decimals round down, toward the past, as they do for positive values: -1.5 is 1969-12-31T23:59:58.500Z, half a second before -1, not after it. A JavaScript Date reaches back to the year -271821, but not every system accepts negative values: MySQL's TIMESTAMP starts at 1970-01-01 00:00:01 UTC.
Options
| Option | Values | Default | When to change it |
|---|---|---|---|
| Unit | Auto, Seconds, Milliseconds, Microseconds, Nanoseconds | Auto | Auto reads the unit from the digits. Choose one when a small value counts milliseconds, or when the source documents its unit. |
| Time zone | Local, UTC | Local | Where a timestamp's date is also shown, and where a date without an offset is read. Every IANA zone your browser knows is in the list. |
Common errors and fixes
| Code | What it means | How to fix it |
|---|---|---|
TIME_Error | The timestamp holds something other than a number: thousands separators, a decimal comma, a unit such as ms, or a date. | Leave digits, a sign, a point and an exponent; a date goes into Date to timestamp. |
TIME_Error | The value lies beyond what a JavaScript Date holds, 100 million days either side of 1970: usually extra digits or the wrong unit. | Check the digits, and the Unit if you chose one. |
TIME_Warning | A value below 100,000,000 is a time before 1973 in seconds, or one on the first day of 1970 in milliseconds. | Choose the unit under Unit if it is not seconds. |
TIME_Error | The date is not in ISO 8601 form, or names a day, hour or second that does not exist, such as February 30, 24:00 or 23:59:60. | Follow the message: it marks the part and gives the rule. |
TIME_Warning | The local time falls in the hour that the clocks skip when daylight saving time starts. | Nothing breaks: the time was moved forward by the jump. Give an offset to name the exact moment. |
TIME_Warning | The local time happens twice, because the clocks go back when daylight saving time ends. | The earlier moment is used; give the later one's offset to choose it. |
TIME_Note | The time lies outside 1901-12-13T20:45:52Z to 2038-01-19T03:14:07Z, the range of a signed 32-bit time_t. | Nothing to fix here; make sure the system that keeps the value stores 64-bit time. |