Support for ISO8601 durations in TimeSpan

[jeremyVignelles]

Rationale

As far as I know, there is currently no support for ISO8601 durations for TimeSpan.Parse and TimeSpan.ToString.

Per wikipedia's definition , it would allow to write durations like P10M1D for a duration of ten month and one day, P1DT2H10M for 1 day, 2 hours and 10 minutes, or PT0,5M for 30 seconds.

Proposition

• Make TimeSpan.Parse() accept arguments like the values quoted above
• Create a new ToString() format specifier to output values like P1DT2H or, if it is not possible for compatibility reasons, add a new .ToISOString() method.

Use cases

• Interoperability with other language and tools by using a standard for representing durations.
  • PHP's DateInterval
  • Java's Duration.parse
  • moment.js
• Allows to fix a JSON deserialization issue in the popular's JSON.net library
• Avoids a reference to XmlConvert.ToString() to convert this, as suggested here

[Clockwork-Muse]

Implementation note: we'd have to adopt a non-quite-conforming parser/formatter (similar to Java's Duration.parse(...), because ISO8601 durations are positive only, and TimeSpan allows for negative values

[bartonjs]

TimeSpan also doesn't know what "months" are, since "2 months and a day" is anywhere from 60 days (Jan/Feb or Feb/Mar in a non-leap-year) to 63 (Dec/Jan); which is a pretty large range for a single-value with a 100ns precision.

P63D would be possible input/output; if the negative problem is ignored.

[khellang]

This would be a great first step for https://github.com/dotnet/corefx/issues/38641.

[lomholdt]

Is there any timeline on this suggestion, or is it currently only a thing on the backlog?
Also, does anyone have a recommended/good way to handle this until support has been added natively?
I have searched but only found some relatively unused libs.

[eiriktsarpalis]

Related to #29932. In the context of System.Text.Json we have decided that ISO8601 durations (which represent duration relative to a point in time) are somewhat incompatible with TimeSpan (which represents an absolute timespan counted in ticks).

[tthiery]

Also interested. I understand that it conflicts with TimeSpan but there are tons of use cases to express duratoins in something else than days (and hours/minutes). Especially since DateTime itself has suitable AddMonths/AddYears/... which are adhering the difference between "P1M" and "P30D" (checked at least for months). I have two cases, one at home and one at work in completely different fields.

Would not be there a case for a Iso8601TimeSpan?

.NET 8 maybe? 😉 I know it is painful since TimeSpan is so ... fundamental ... but so ISO8601 compliance ;)

FYI: @terrajobst

[eiriktsarpalis]

Would not be there a case for a Iso8601TimeSpan?

I would recommend filing a separate API proposal for a potential System.Duration type. In the meantime, I'm going to close this issue as we made the definitive decision back in .NET 6 to not support the ISO 8601 duration format for System.TimeSpan.