Time & Time Zones

Details and how to verify this yourself: Security & privacy.

The tool sits in a window that works like a desktop app: menus on the top row and the full-screen icon at its right (Esc leaves full screen). The set-up options described below are in Settings → Options…, an overlay, and the Settings menu also lists the common choices directly. To keep the options in view instead, choose View → Inline config; the page remembers that choice. Help → Keyboard shortcuts… lists the keys.

The page has four panels.

1. Now. The current time in your browser’s zone and in any IANA zones you list, updated every second. It shows the UTC offset, the zone abbreviation, and whether daylight saving time (DST) is in effect.

2. Convert. Paste almost any timestamp to see it in UTC, as a Unix timestamp, and in other zones:

   • ISO 8601 / RFC 3339: 2026-10-13T14:30:00Z, 2026-10-13T14:30:00+02:00, 2026-10-13 14:30, 2026-10-13
   • an email or HTTP date: Tue, 13 Oct 2026 14:30:00 +0200
   • a Unix timestamp in seconds, milliseconds, microseconds or nanoseconds
   • the word now

   A time without an offset (2026-03-08 02:30) is a wall-clock time. It is read in the zone given under Zone for times without an offset, which defaults to your browser’s zone. The summary line says exactly how the input was read. If the wall-clock time was skipped or repeated by a DST change, it says so.

3. Difference. Two times give both the calendar difference (P1M2D, “1 month, 2 days later”) and the elapsed time (PT23H, total hours, seconds and milliseconds). The two differ across a DST change: noon to noon over the spring change is one calendar day, but only 23 hours.

4. Add. Add or subtract an ISO 8601 duration such as P1D, PT36H or -P1M. Days, weeks, months and years keep the wall-clock time; hours, minutes and seconds are exact elapsed time.

Why “P1D” and “PT24H” differ. In New York, 2026-03-07 12:00 plus P1D is 2026-03-08 12:00 (23 hours later, because clocks moved forward). Plus PT24H it is 2026-03-08 13:00. Use days for “same time tomorrow” and hours for “exactly 24 hours later”.

For agents. Call time_now instead of assuming today’s date. Pass explicit zones such as America/New_York; abbreviations such as EST are refused because they are ambiguous. Read notes in the response: they list every assumption that was made.

Input formats. Inputs are tried in this order; the first that matches wins.

Unix timestamp units. With unit=auto (the default), the unit follows the magnitude of the integer part:

Each threshold is 10^11 of the smaller unit (1973-03-03) and the year 5138 in the larger unit, so any date from March 1973 to 5138 is detected correctly whatever its unit. A millisecond timestamp before March 1973 is read as seconds: pass unit. An auto-detected unit is always reported in notes, together with what the number would mean in the neighbouring units. Pass unit to override it. Parsing is exact (big integers), then rounded down to the millisecond, which is the resolution of every result. When digits were dropped, notes says so.

Range. Instants must lie within ±8.64 × 10^15 ms of 1970-01-01T00:00:00Z (the JavaScript Date range, years −271821 to 275760).

Wall-clock times. An input without an offset has no meaning until a zone is given.

• Which zone: time_convert uses from_zone and fails without it; time_diff and time_add use zone (default UTC). A bracketed [Zone] in the input takes precedence.
• How it resolves: the resolver finds every instant whose local time in that zone equals the input. The result is reported in local_time:

These are the rules of JavaScript Temporal’s disambiguation option. If both an offset and a bracketed zone are present, the offset decides the instant; a mismatch between them is reported in notes.

Zones.

• Accepted:
  • IANA names, with letter case corrected (america/new_york → America/New_York);
  • UTC (also GMT, Z, Zulu);
  • fixed offsets ±H, ±HH:MM, UTC±HH:MM or GMT±HHMM, up to ±18:00, reported as UTC±HH:MM.
• Rejected:
  • local and system;
  • unknown names;
  • the abbreviations PST, PDT, EST, EDT, CST, CDT, MST, MDT, BST, CET, CEST, IST, JST, AEST and AEDT, each with a suggested IANA zone. Some of these are valid IANA names, but they are fixed offsets without DST, or now aliases of an unexpected zone.
• Warnings:
  • fixed offsets (they never change for DST);
  • legacy names without a / (such as Japan);
  • Etc/GMT±N, whose sign is inverted: Etc/GMT+5 is UTC−05:00.

Output for each zone.

unix_seconds is rounded down, so −0.5 s is −1.

Durations.

• Grammar: [+|-]P[nY][nM][nW][nD][T[nH][nM][nS]], case-insensitive, with at least one component. Weeks may be combined with other units, as ISO 8601-2 and Temporal allow.
• Fractions: only on the smallest of hours, minutes and seconds, with . or ,, to whole milliseconds. PT1.5H is normalised to PT1H30M.
• Rejected: fractional years, months, weeks or days (P1.5D), because those units have no fixed length.
• API alternative: amount with amount_unit (years … milliseconds). subtract=true negates the duration.

Addition (time_add) follows Temporal.ZonedDateTime.prototype.add:

1. Years and months are added to the wall-clock date in zone. A day that does not exist in the target month is clamped to its last day (Jan 31 + P1M = Feb 28; Feb 29 + P1Y = Feb 28). Clamping is reported in notes.
2. Weeks (7 days) and days are added to the wall-clock date.
3. The resulting wall-clock time is resolved in zone with disambiguation, as in the table above.
4. Hours, minutes, seconds and milliseconds are added as exact elapsed time.

A duration with no calendar part (only PT…) never consults the zone’s rules. The offset written in input does not choose the zone: 2026-03-07T12:00-05:00 plus P1D in UTC is exactly 24 hours later.

Differences (time_diff).

• total: exact elapsed time, end minus start (signed); a day is 86,400,000 ms. Values other than milliseconds are IEEE 754 doubles and may be fractional.
• calendar: counted forward from the earlier to the later instant in zone, largest units first. Months are the largest whole number that does not pass the later instant, then days the same way. The rest is elapsed hours, minutes, seconds and milliseconds. Magnitudes are non-negative; sign gives the direction. By construction, time_add of calendar to the earlier instant in the same zone returns the later instant exactly; the test suite checks this over thousands of random pairs in DST zones.
• iso_duration: the calendar breakdown as ISO 8601, prefixed with - when end is before start (the ISO 8601-2 / Temporal convention), or PT0S. Weeks are not used.
• iso_duration_exact: elapsed time in hours, minutes and seconds only (PT23H).
• calendar_days: the local date of end minus the local date of start in zone, ignoring time of day.

Limits. Inputs up to 100 characters; up to 20 zones per request; pattern up to 100 characters.