Timestamp converter

A whole number (a fraction is allowed) is read as Unix time, and the count of digits before the point picks the unit, leading zeros not counted: up to 11 digits is seconds, 12 to 14 is milliseconds, 15 to 17 is microseconds, 18 to 20 is nanoseconds; more is refused. Each line falls on 1973-03-03 in the smaller unit and the year 5138 in the larger, so a timestamp from the last five decades is unambiguous and a number reaches from the year −1199 to 5138. A value in the finer unit from before 1973-03-03 would be misread as the coarser one — type it as a date instead. The digits are moved to milliseconds as a decimal string in BigInt, not floating point; anything finer than a millisecond is dropped, rounding down to the whole millisecond — for a time before 1970, the earlier one — and Read as says when that happened.

A string shaped like ISO 8601 / RFC 3339 is checked field by field first, because Date.parse rolls 2026-02-30 over into March: the year is 4 digits or a sign and 6, the month 01–12, the day one that exists in that month, the hour 00–23, minute and second 00–59, an offset hour 00–23. 24:00 and a leap second 60 are refused. A space may stand for the T, as RFC 3339 allows, and the offset may be written +02:00, +0200 or +02; the page respells it as +02:00 and says so. Then Date.parse reads it under the ECMAScript rules: a date alone is UTC midnight, a date and time with no offset is local time, Z or an offset is honoured, and fraction digits beyond milliseconds are dropped. A local time is read back through the local getters; when it falls in a gap the clocks skip, or in a stretch they repeat when they go back, a notice says so and shows which instant this engine chose. The repeat check tries the offsets in force a day before and a day after, so two changes within one day can go unnoticed. Anything else also goes to Date.parse, but what it accepts beyond ISO is engine-dependent — "Aug 24 2026" reads in Chrome and Firefox; do not build on it. A date written year first with slashes, dots or one-digit fields (2026/08/24), or month first with slashes (08/24/2026), has its month and day checked the same way first, so it cannot roll over either.

A Date holds milliseconds since 1970-01-01T00:00:00Z as a number, and its range is ±8,640,000,000,000,000 ms, about ±273,000 years; beyond that the tool refuses. Unix time has no leap seconds: every day is exactly 86,400 s, so the 27 leap seconds inserted since 1972 are not in these numbers, and a leap second is a repeated 23:59:59, not a count. ISO UTC comes from toISOString. The offset form is built from the component getters, and its offset is the difference between those local fields and UTC, to the second — not getTimezoneOffset, which can drop the seconds, while local mean time before standard zones had seconds in it (Rome was +00:49:56 until 1893). An offset with seconds is printed as ±HH:MM:SS, which RFC 3339 does not allow and Date.parse does not read back. The written-out form and the weekday come from Intl.DateTimeFormat in this browser's language; relative time uses Intl.RelativeTimeFormat with the largest unit that fits, rounded to a whole unit, with a month taken as 30.44 days and a year as 365.25. Day of year counts from 1 January. ISO week: weeks start on Monday and week 1 is the week that holds 4 January, so 1–3 January can belong to the last week of the previous year and 29–31 December to week 1 of the next. The tool takes the Thursday of the input's week, and counts weeks from the Monday of that year's week 1.

The rows marked with the zone depend on this device's zone setting, read from Intl.DateTimeFormat().resolvedOptions().timeZone, and on the browser's copy of the zone database; change the operating system's zone and they change. The UTC switch makes those rows use UTC instead. "Now" and the ticking clock use Date.now() and a 1,000 ms setInterval — that is this device's clock, which can itself be wrong. Input over 200 characters is refused; no date needs more. Nothing is uploaded: there is no server in this file.

Other time zones reads twelve places from the browser's own copy of the IANA zone database, through Intl.DateTimeFormat with a timeZone: UTC, America/Los_Angeles, America/Denver, America/Chicago, America/New_York, Europe/London, Europe/Paris for Central Europe, Europe/Athens for Eastern Europe, Asia/Kolkata, Asia/Shanghai, Asia/Tokyo and Australia/Sydney. Each offset is worked out to the second from the wall-clock fields the database gives for that instant, so summer time and past rule changes count as far as this browser's database knows them. The abbreviation — PST or PDT, CET or CEST — comes from a small table in this page and is printed only when the offset is that place's present standard or summer offset; for a date before its rules settled, or while they were different, the row gives the offset alone rather than guess a name. China's CST is China Standard Time, not US Central. Each row shows the time to the second, the date in this browser's language (with the year when it is not this year), how many calendar days it sits ahead of or behind this device for the same instant, and the offset in short form; Copy copies the full ISO 8601 form with offset and milliseconds. A row that matches this device's zone says so.

The Dark button remembers its setting in this browser's local storage. Nothing you type or drop into the page is stored.