supporting exceeding the values range in duration?

[ringostarr80]

What do you think about exceeding the values range in a duration like: 'P90D' for 90 days.

As stated here

The standard does not prohibit date and time values in a duration representation from exceeding their "carry over points" except as noted below. Thus, "PT36H" could be used as well as "P1DT12H" for representing the same duration. But keep in mind that "PT36H" is not the same as "P1DT12H" when switching from or to Daylight saving time.

I know that you stated here

I'd be fine with picking reasonable values here (e.g. not more digits than it makes sense for the unit, that is 2 digits (range 0-60) for minutes, ...).

... to explicitly not allow exceeding values, but you can maybe add a new function e.g.: 'duration_allow_exceed(string: &str)'!?

[emarsden]

I ran into this parsing MPEG DASH manifests, where durations are specified using the ISO 8601 standard, and where some manifests in the wild use durations like "PT344S" example.

The ISO 8601:2004 standard, at least as integrated in Indian Standard 7900:2007, which is available online without paying extortionate fees to ISO, includes an example on page 29 of "PT72H" which is not parsed correctly by this crate (I realize that examples are not normative, but clearly show the intent of the authors here). It states on page 21 "In these representations the maximum number of digits in a component needs to be agreed by the partners in information interchange".

Would you accept a PR allowing as many digits in these duration components as fit in a u32?