ISO 8601 Duration Calculator
Build and parse ISO 8601 duration strings (PnYnMnDTnHnMnS). Convert between human-readable durations and ISO format for APIs, schema markup.
ISO 8601 Duration Calculator
Calculator
Adjust values & calculateEnter your values below. Every result is computed in your browser โ no data is sent to any server.
Formula: P[n]Y[n]M[n]W[n]DT[n]H[n]M[n]S
Worked example โ ISO 8601 Duration: PT2H15M30S | Total seconds: 8,130 | Total minutes: 135.50
Formula
P[n]Y[n]M[n]W[n]DT[n]H[n]M[n]S
P designates the period (required). Date components follow: Y (years), M (months), W (weeks), D (days). T separates date from time components: H (hours), M (minutes), S (seconds). Each n is a positive integer. Components with zero values are omitted. Approximate conversions use 365 days per year and 30 days per month.
Worked Examples
Example 1: Building a Video Duration for Schema Markup
Problem:A video is 2 hours, 15 minutes, and 30 seconds long. Generate the ISO 8601 duration for use in schema.org VideoObject markup.
Solution:Hours: 2, Minutes: 15, Seconds: 30 No date components needed ISO 8601 = P + T + 2H + 15M + 30S = PT2H15M30S This can be placed in the duration property of a VideoObject schema.
Result:ISO 8601 Duration: PT2H15M30S | Total seconds: 8,130 | Total minutes: 135.50
Example 2: Parsing an API Subscription Period
Problem:An API returns the subscription duration as P1Y3M15D. Parse this into human-readable form and calculate approximate total days.
Solution:P1Y3M15D parses as: Years: 1, Months: 3, Days: 15 Approximate total days = 1 x 365 + 3 x 30 + 15 = 365 + 90 + 15 = 470 days Total hours = 470 x 24 = 11,280 hours Total seconds = 470 x 86,400 = 40,608,000
Result:Human readable: 1 year, 3 months, 15 days | Approx. 470 days | 40,608,000 seconds
Frequently Asked Questions
What is the ISO 8601 duration format and where is it used?
ISO 8601 is an international standard for representing dates, times, and durations. The duration component uses the format PnYnMnWnDTnHnMnS, where P marks the beginning of a duration (for period), followed by optional date components (Years, Months, Weeks, Days) and time components preceded by T (Hours, Minutes, Seconds). For example, P1Y2M3DT4H5M6S represents 1 year, 2 months, 3 days, 4 hours, 5 minutes, and 6 seconds. This format is widely used in programming languages, APIs, databases, calendar applications, schema markup for search engines, video metadata, subscription services, and project management tools because it provides a language-independent, unambiguous way to express time durations.
How do I read and interpret ISO 8601 duration strings?
An ISO 8601 duration string always starts with the letter P (for period). Everything after P and before T (if present) represents the date portion: Y for years, M for months, W for weeks, D for days. The letter T separates date from time components. After T: H represents hours, M represents minutes, and S represents seconds. Note that M means months before T and minutes after T. Some examples: PT30M means 30 minutes, P7D means 7 days, P1Y6M means 1 year and 6 months, P2DT12H means 2 days and 12 hours, and PT1H30M means 1 hour and 30 minutes. Any component with a zero value can be omitted. The W (week) designator cannot be combined with other date components in strict ISO 8601, though many implementations allow it.
Why are month and year durations considered ambiguous in ISO 8601?
Months and years in ISO 8601 durations are ambiguous because they do not correspond to fixed numbers of seconds. A month can be 28, 29, 30, or 31 days depending on which month and whether it is a leap year. Similarly, a year is 365 or 366 days. This means P1M starting from January 31st might end on February 28th or March 3rd depending on interpretation. For this reason, many programming libraries use a convention of 30 days per month and 365 days per year when converting to absolute time, but this is only an approximation. When precision matters, such as in scientific computing, financial calculations, or scheduling, it is best to use durations in days, hours, minutes, and seconds rather than months and years to avoid ambiguity.
How is ISO 8601 duration used in web development and APIs?
ISO 8601 durations appear extensively in modern web development. In HTML and schema markup, the datetime attribute on time elements uses this format for accessibility and search engine optimization. Google structured data for recipes, videos, events, and courses all require ISO 8601 durations to specify cooking times, video lengths, event durations, and course completion times. REST APIs commonly use this format for timeout values, retry intervals, cache expiration, subscription periods, and scheduling endpoints. YouTube and other video platforms use ISO 8601 durations in their API responses to represent video lengths. In JavaScript, libraries like Luxon and date-fns support parsing and formatting ISO 8601 durations natively, making it the de facto standard for duration representation in web applications.
How do different programming languages handle ISO 8601 durations?
Most modern programming languages have built-in or library support for ISO 8601 durations. Java introduced the Duration and Period classes in java.time (Java 8+), where Duration handles time-based amounts and Period handles date-based amounts. Python has the isodate library for parsing ISO 8601 durations, and the timedelta class for representing absolute durations. In JavaScript, the Temporal API proposal includes Duration support, and libraries like Luxon provide Duration.fromISO() for parsing. C-sharp has XmlConvert.ToTimeSpan() for parsing ISO 8601 durations. Go uses the standard time.ParseDuration with a slightly different syntax but third-party packages handle ISO 8601. PHP has the DateInterval class that directly accepts ISO 8601 duration strings via its constructor. Understanding these implementations helps developers work with duration data across polyglot microservice architectures.
What is the difference between an ISO 8601 duration and an ISO 8601 interval?
A duration such as PT2H is a bare length of time with no position on the calendar. An interval anchors that length: it is written as two values separated by a solidus, either start and end (2026-01-01T09:00Z/2026-01-01T11:00Z), start and duration (2026-01-01T09:00Z/PT2H), or duration and end (PT2H/2026-01-01T11:00Z). Prefixing an interval with R and a count produces a repeating interval, so R5/2026-01-01T09:00Z/P1D means five daily repetitions.
Can an ISO 8601 duration contain decimal values?
The standard permits a decimal fraction on the smallest component actually present, and only on that one, using either a comma or a full stop as the separator. PT0.5H therefore means thirty minutes and PT1.75S means one and three-quarter seconds. In practice most implementations narrow this considerably: the XML Schema duration type and Java's Duration.parse accept a fraction only on the seconds field, so PT0.5H is rejected. The parser on this page follows the same restriction and allows fractions only on seconds.
How do you write a zero-length duration correctly?
A bare P is not valid, because the grammar requires at least one numeric component after the designator, and a lone T with nothing after it is invalid too. The conventional zero values are PT0S when the quantity is time-based and P0D when it is date-based; Java formats Duration.ZERO as PT0S and Period.ZERO as P0D for exactly this reason. Emitting an empty string instead is a frequent source of parse failures in APIs that expect a duration field. Note that the parser on this page is lenient here: it accepts a bare P and reports it as a zero duration rather than rejecting it, so do not treat acceptance by this tool as proof that a downstream parser will agree.
Are negative ISO 8601 durations allowed?
The core duration grammar describes a non-negative amount of time, so a plain ISO 8601 duration cannot be negative. Several profiles extend it: the XML Schema duration type permits a leading minus sign, as in -P1D, and Java's Duration.parse accepts both a leading sign and signed individual components. Direction is more often carried outside the string, by the field name or by the order of an interval's endpoints, so check the receiving parser before emitting a signed value.
Should a monthly subscription period be encoded as P1M or P30D?
Use P1M when the billing date should track the calendar, and P30D only when every cycle must be exactly the same length. P1M is applied relative to a start instant, so a subscription starting 15 March renews 15 April regardless of month length; when the anchor day does not exist in the target month, most calendar-aware libraries clamp to the last valid day, turning 31 January into 28 or 29 February. P30D never clamps but drifts steadily earlier through the year.
References
Background & Theory
History
Reviewed for accuracy by Daniel Agrici, Founder & Lead Developer ยท Editorial policy
Related Calculators
๐งฎBandwidth Time Transfer Calculator
Calculate bandwidth time transfer with inputs, formulas, and instant results.
๐งฎDownload Time Calculator
Calculate download time with inputs, formulas, and instant results.
๐งฎThroughput Efficiency Calculator
Calculate throughput efficiency with inputs, formulas, and instant results.
๐งฎBase64 Encode & Decode Calculator
Calculate base64encode decode with inputs, formulas, and instant results.
๐งฎHash Checksum Calculator
Calculate hash checksum with inputs, formulas, and instant results.
๐งฎUrlpercent Encoding Calculator
Calculate urlpercent encoding with inputs, formulas, and instant results.