Closed dcastro closed 1 year ago
Hmm, it would be better if the CalendarDiffTime
type were changed...
Yes I thought so too, but didn't want to suggest a breaking change ^^ If you're okay with that, I'm all for it!
So this part I definitely want to fix:
> formatParseM durationTimeFormat "P1DT1S"
P0MT86401S
The Show
instance should use larger units, and in this case should return "P1DT1S".
On the other hand, I would prefer 12H + 12H = 1D: this is what people expect. I don't think it's worth supporting leap-seconds in this type. So I don't think the type should be changed.
OK, fixed the Read
and Show
instances to use the ISO8601 code.
If I understand things right, as of #40, we can parse
"P1DT1S"
toCalendarDiffTime
usingdurationTimeFormat
:However,
CalendarDiffTime
normalizes the "days" and "weeks" units (D
andW
) and assumes all days have a standard 24 hours.On the other hand, the parser
durationDaysFormat
forCalendarDiffDays
does correctly handle "days" and "weeks", but it does not handle smaller time units like hours and seconds.Should there be a type that handles strings like
P1DT1S
correctly? A type with 3 fields, for months, days, andNominalDiffTime
?