Closed zoewithabang closed 5 years ago
Interesting, I did not know about that (and find them a bit weird and think communicating a duration in a single unit seems much easier and less error prone to parse).
I don't have any hesitations against having a parser in here, seems independent enough from all the date/time stuff (except hopefully sharing some of the internal parsers).
However there's a slight difficulty (emphasis mine):
Leading zeros are not required, but the maximum number of digits for each element should be agreed to by the communicating parties.
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, ...). We should just properly document that.
Sounds good. I agree on finding them a bit weird, I just came across their use as part of the YouTube API's video structure but hadn't heard of them beforehand.
Is it reasonable to base this feature off the nom5 branch? I assume landing that first would be preferable given the refactoring involved.
I didn't merge that yet? Yes, base it on that, I try to get that merged sometime this week
Would adding support for ISO 8601 durations be desirable for this crate? I was looking for a parser for them and thought it would make sense for this crate to support them.
I'd be happy to give implementing them a go myself if there aren't any objections. 🙂