dev101.io

ISO 8601 Interval Parser

Parse start/end, start/duration, and duration/end intervals including repeats.

← Back to the full ISO 8601 Parser

Loading tool…

ISO 8601 intervals and repeats

An ISO 8601 interval is two timepoints — or a timepoint plus a duration — separated by a forward slash. The standard defines three forms and a repeating-interval extension:

  1. Start / End. 2024-01-01T00:00:00Z/2024-12-31T23:59:59Z — two absolute datetimes. The end is exclusive or inclusive depending on convention; ISO 8601 itself leaves this implementation-defined, which is why query languages like TSQL and Prometheus document their stance explicitly.
  2. Start / Duration. 2024-01-01T00:00:00Z/P1Y — a start followed by a duration. This tool resolves the end by adding the duration (using calendar-accurate math for years/months when the start is anchored).
  3. Duration / End. P1Y/2024-12-31T00:00:00Z — a duration followed by an end. Symmetric to form 2; the tool subtracts.
  4. Repeating interval. Prefix any of the above with R[n]/. R/PT30M means "repeat every 30 minutes forever"; R5/2024-01-01T00:00:00Z/P1D means "five repetitions of a one-day interval starting 2024-01-01". The R alone (no number) means infinite repeats.

Repeating intervals are widely used by standards-compliant schedulers: iCalendar (.ics, Google Calendar, Outlook), RFC 5545, and many industrial-automation buses. The iCalendar RRULE vocabulary is richer, but ISO 8601's R form is the interop baseline — any calendar API that exports ISO 8601 will use it.

Practical tip. When a start has an explicit timezone offset and an end does not (or vice versa), this parser warns: the computed duration is well-defined (offsets don't change wall-clock deltas), but humans reading the output frequently assume both endpoints are in the same zone when they aren't. Normalise to UTC or to a single tz before persisting.

Paste an interval below and the parser will show the resolved start, end, duration, and any repetition count.

Frequently asked questions

Is the end of an ISO 8601 interval inclusive or exclusive?

ISO 8601 does not specify — it's left to the consuming system. Prometheus, TSDB, and most time-series databases treat the end as _exclusive_ (so "2024-01-01T00:00:00Z/2024-01-02T00:00:00Z" covers exactly 24 hours and doesn't double-count the boundary). Calendar systems like iCalendar often treat the end as _inclusive_. This tool reports the raw duration between the two endpoints without taking a stance — what you do with the last second is up to your query engine. When building APIs, document your convention in the spec and in the response schema.

What does the 'R' prefix mean, and how does it interact with 'RRULE'?

"R[n]/" is ISO 8601's native way to express a repeating interval: "R5/2024-01-01/P1D" means five daily repetitions starting 2024-01-01; "R/PT30M" means every 30 minutes forever. iCalendar's "RRULE" is a richer DSL layered on top that adds byday, bymonth, byhour, and other constraints — but any iCalendar VEVENT also carries a DTSTART, DTEND, and DURATION that are themselves ISO 8601. If you only need "every N seconds/minutes/days", the ISO R-form is all you need and is easier to parse than an RRULE. If you need "every Tuesday in March except the second one", reach for RRULE.

Can the start and end have different timezone offsets?

Yes, and this tool will parse them — but the result is a _duration in UTC_, not a "5 hours in London time" interval. Offsets affect wall-clock interpretation, not elapsed-time math. If your system cares about local wall-clock (e.g. scheduling a recurring event that keeps firing at 9am local even across DST transitions), the right abstraction is iCalendar's VTIMEZONE + RRULE, not a raw ISO 8601 interval. For durations between two absolute timestamps, mixed offsets are fine and unambiguous.

Other ISO 8601 Parser cases

This is a variant landing page for ISO 8601 Parser. Every transform runs in your browser — nothing you paste is sent to our server or any third party.