Skip to content
ToolBoxGeniehome

ISO 8601 Duration Converter

Developer Tools · Added

ISO 8601 durations are what APIs use when they mean a length of time rather than a moment — YouTube video lengths, Kubernetes timeouts, XML Schema fields. They are easy to read once and hard to remember, and this converts them in both directions.

Starting from

P for period, then years, months, weeks and days — then T, then hours, minutes and seconds.

Try:

Result

In words

1 hour 30 minutes

Written back in canonical form as PT1H30M

Seconds
5,400.0000

Exact

Minutes
90.0000

Exact

Hours
1.5000

Exact

Days
0.0625

Exact

Weeks
0.0089

Exact

Milliseconds
5,400,000

Exact

Components

Years
0
Months
0
Weeks
0
Days
0
Hours
1
Minutes
30
Seconds
0
ISO 8601 form
PT1H30M

The letter M means months before the T and minutes after it — P1M is a month, PT1M is a minute, and that is the whole reason the T is mandatory. One more trap worth knowing: adding a month to a date is not the same as adding a month of seconds. 31 January plus one month is 28 February in most implementations, while adding the equivalent seconds lands on 2 March. Calendar arithmetic and elapsed time are different operations.

How to use the iso 8601 duration converter

  1. 1Paste an ISO duration such as PT1H30M, or switch the direction and type it in words.
  2. 2Read the totals in seconds, minutes, hours and days.
  3. 3Check the components table if you are checking a value field by field.
  4. 4Watch for the note about years and months, which do not have a fixed length.

Examples

An hour and a half

Input
PT1H30M
Result
5,400 seconds · 90 minutes · 1.5 hours

The M problem

Input
P1M against PT1M
Result
One month against one minute — the T is the only difference

About the iso 8601 duration converter

Why a duration format exists at all

A number of seconds is unambiguous and unreadable: 5400 says nothing until you divide it. A string like "1h 30m" is readable and unparseable, because every codebase invents its own spelling. ISO 8601 durations are the compromise — one grammar, readable enough to check by eye, strict enough to parse without heuristics.

That is why they turn up wherever a duration crosses a boundary between systems: an API response, a configuration file, a database column, a message schema.

The fixed and the calendar-dependent parts

Weeks, days, hours, minutes and seconds are fixed quantities and convert to seconds exactly. Years and months are not quantities at all until anchored to a date, which is a genuine property of the calendar rather than a limitation of any parser.

The practical consequence is to keep them apart. A timeout, a cache lifetime or a retry interval should be expressed in the fixed units, where the value means exactly one thing. A billing period or a subscription term belongs in months, and should be applied by calendar arithmetic rather than converted to seconds at all.

Frequently asked questions

Why does M mean two different things?
It means months in the date part and minutes in the time part, and the T that separates them is what tells you which. P1M is a month, PT1M is a minute. Leaving out the T is the single most common way one of these strings is written wrong, and it produces a value about 43,800 times too large.
How many seconds is P1M?
There is no answer, and any tool that gives one without saying so is guessing. A month is 28 to 31 days depending on which month, and a year is 365 or 366. This reports the fixed part of a duration exactly, and where years or months appear it says which portion is an estimate and shows the conventional averages it used — 365.2425 days to a year, and a twelfth of that to a month.
Is adding P1M to a date the same as adding a month of seconds?
No, and this catches people in production. Calendar arithmetic moves the month field and then clamps: 31 January plus one month is 28 February in most implementations. Adding the equivalent number of seconds lands on 2 March instead. Which behaviour you want depends on whether you are scheduling or measuring.
What is the W component?
Weeks. The specification says a week component should stand alone — P2W rather than P2W3D — though most parsers accept it mixed. A week is exactly seven days, so unlike months it converts to seconds without an assumption.