ISO 8601 duration calculator

How to use

1. Type a duration in ISO 8601 duration. It starts with P; years, months, weeks and days follow, then T and hours, minutes and seconds. Each part is a number followed by its letter: P3Y6M4DT12H30M5S. The buttons fill in examples.
2. Read the two verdicts. ISO 8601 follows the standard as published summaries describe it; Temporal follows the format that JavaScript's Temporal.Duration accepts, as MDN documents it. They differ on a few strings (weeks mixed with days, signs, fractions on days). Reasons are shown when a verdict is not valid.
3. For a valid duration, the page shows its components and, when it has no years or months, its length in seconds. If it has only hours, minutes and seconds, that length is exact. If it has days or weeks, the page labels it "nominal length" because it counts a day as 24 hours, which a calendar day is not across a clock change. With years or months it says "no fixed length".
4. To apply it to a date, type a Start (YYYY-MM-DD hh:mm:ss), choose the zone and whether to add or subtract. The result shows the new local time with its offset, the instant in UTC, and the elapsed time between start and result.

The date parts (years, months, weeks, days) are applied to the local calendar date first, with a month-end clamped to the last day of the month; the time parts (hours, minutes, seconds) are then applied as elapsed time. That is the order the page's examples use, and it is why P1D and PT24H can differ.

Worked examples

Every result printed here is recomputed by an automated test from the same engine as the tool; the date arithmetic is also checked against Python's datetime and JavaScript's Date in the tests.

Reading a duration

Only a duration made of hours, minutes and seconds has a fixed length, such as PT1H30M. When it contains days or weeks, such as P1DT12H or P2W, the page shows a "nominal length", which counts a day as 24 hours and a week as 7 days. That is a convention of this tool, not a property of the duration: Wikipedia's summary of ISO 8601 notes that the number of seconds in a calendar day is ambiguous (it names leap seconds), and applied to a date in a zone with clock changes a calendar day may be 23 or 25 hours, as the next examples show. Years and months have no fixed length at all.

A day is not 24 hours: P1D versus PT24H

New York's clocks go forward on 7 to 8 March 2026 and back on 31 October to 1 November (the 2026 autumn change is at 02:00 on 1 November).

One calendar day later is noon again, but only 23 hours have passed. Twenty-four hours later is 13:00.

In the autumn, one calendar day is 25 hours, and 24 elapsed hours end at 11:00.

PT36H versus P1DT12H

Months at the end of the month

The elapsed time is different each time (672, 696 and 744 hours), which is why a month has no fixed length. Adding then subtracting a month does not always return to the start: 31 January plus P1M is 28 February, and 28 February minus P1M is 28 January.

A month that lands in a clock gap

8 February 02:30 plus one month would be 02:30 on 8 March, which does not exist in New York. The tool uses the same rule as the time zone converter (default: shift later), giving 03:30.

What goes wrong

Invalid or surprising durations. Each result is the tool's exact output.

Missing pieces

Letters in the wrong place

A typical slip is P1H for "one hour": the hours, minutes and seconds designators belong after the T. The same applies to M, which is months before the T and minutes after it, so P5M is five months and PT5M is five minutes. Wikipedia's summary of ISO 8601 uses the same P1M and PT1M pair to explain the T.

Where the standard and the libraries differ

A decimal fraction is allowed only on the smallest component that is present (Wikipedia's summary: "the smallest value used may also have a decimal fraction"), written with a full stop or a comma. That is why PT1.5H and PT1,5H are valid and PT1.5H30M is not. A string that fails this rule gets no length, components or date result from the tool, only the reason.

If a duration comes from a system you do not control, check which parser reads it: the same text can be accepted by one library and refused by another.

Storing 24 hours when you meant "a day"

"Repeat every day" and "repeat every 24 hours" are different instructions in a zone with daylight saving. See the first pair of examples: after one of each, one lands at noon and the other at 13:00.

Limits & gotchas

• ISO 8601 was not read. The standard is sold, not published free. The ISO verdict follows the summary of the standard on Wikipedia and the documentation of java.time.Period. Where editions or extensions differ (for example, signed durations in ISO 8601-2), the page says what it did.
• The Temporal verdict is from MDN's description, not from running Temporal: it was not available in the JavaScript used for testing the site.
• How a duration is applied to a date is a choice of this tool, not part of ISO 8601: date units on the local calendar first (months clamped to the last day), then time units as elapsed time. Libraries differ in details; the examples show what this tool does.
• Years, months and weeks. A week is 7 days and a day is a calendar day when it is applied to a date; the "nominal length" line counts a day as 24 hours, which is a convention of this tool and not what the cited sources define; only durations with hours, minutes and seconds alone get a "fixed length".
• Fractions. A fraction on the smallest time component is converted exactly to nanoseconds, up to 9 digits. A fraction on days, weeks, months or years is valid ISO 8601 but the page cannot apply it to a date and says so.
• Zone data comes from your browser, so a recent rule change may be missing (see the time zone converter).
• Repeating intervals and time intervals (R5/.../P1D) are not handled.

FAQ

Sources

• Wikipedia: ISO 8601 Used for: Calendar, ordinal and week dates; week 1 is the week with the year's first Thursday; the zero offset is written Z or +00:00 (not -00:00); 24:00 was allowed until the 2004 edition, removed in ISO 8601-1:2019 and reintroduced by Amendment 1 (2022); duration syntax PnYnMnDTnHnMnS, "P" alone is invalid, PT0S and P0D are valid, a fraction only on the smallest component, weeks as PnW, and that PT36H and P1DT12H are different durations across a DST change. ISO 8601 itself is sold, not free; it was not read.
• MDN Web Docs: Temporal.Duration Used for: The Temporal duration string format: optional sign, P, years, months, weeks, days, T, hours, minutes, seconds; letters may be lower case; only the last component may be fractional and only a time unit. This page lists that as the Temporal rule; it was read, not executed, because Temporal is not available in the Node used for the tests.
• Oracle: Java SE 21: java.time.Period.parse Used for: Period.parse is based on the ISO-8601 PnYnMnD and PnW forms; the leading sign and negative component values are not part of ISO-8601, and ISO-8601 does not permit mixing PnYnMnD with PnW, although java.time itself accepts a mixed string such as P1Y2M3W4D and multiplies the weeks by 7.
• Oracle: Java SE 21: java.time.ZonedDateTime Used for: For a local date-time that falls in a gap, the zoned date-time is shifted forward by the length of the gap, ending in the later offset; for an overlap the previous offset is retained if there is one, otherwise the earlier offset is used. plusDays works on the local time-line (adding days to the local date-time and converting back), whereas plusHours works on the instant time-line, so adding one hour is always a duration of one hour. Java is not installed on the machine used to build this site, so Java behaviour here is described from the documentation, not executed.
• MDN Web Docs: Date Used for: The supported range (April 20, 271821 BC to September 13, 275760 AD, plus or minus 100,000,000 days); that Date ignores leap seconds; Number.MAX_SAFE_INTEGER is 9,007,199,254,740,991; the date-time string format (a simplification of ISO 8601, 24:00:00 allowed, expanded years of + or - followed by six digits, -000000 disallowed); and that setting a local time inside a DST transition follows the Temporal "compatible" disambiguation: if the local time corresponds to two instants the earlier one is chosen, and if it does not exist the result goes forward by the gap duration (with the New York 2024 example).
• Python Software Foundation: datetime: Basic date and time types Used for: datetime.fold: "Used to disambiguate wall times during a repeated interval"; the values 0 and 1 mean the earlier and later of the two moments.
• IANA: Theory and pragmatics of the tz code and data Used for: The database records the history and the predicted future of civil time scales; names have the form Area/Location (for example Asia/Calcutta was renamed Asia/Kolkata, with the old name kept as a link); the abbreviation list shows that one abbreviation can mean different things (IST appears for India, for Irish time and for Israel).

Every document above was opened and read on 2026-10-03. Documentation changes; if a page here disagrees with the current docs, trust the docs and tell us.

Related tools

• Date difference and add/subtract

  Calendar and elapsed-time arithmetic that is honest about DST, with month-end clamping explained.

• Time zone converter

  Convert a local time between IANA zones and see what happens when the time does not exist or happens twice.

• ISO 8601 and RFC 3339 validator

  Check a date-time against both formats and see exactly why a string is or is not valid.

• DST transition finder

  List every clock change of a zone in a year: the exact instant, the offsets, and the local times skipped or repeated.