Because Jiff spans (like Temporal durations) represent each unit
individually, and because ISO 8601 require the use of fractional seconds
to represent sub-second units, there is an inherent loss of fidelity
when spans are serialized to the ISO 8601 duration format.
For example, a Jiff span like 1 second 2000 milliseconds is distinct from
3 seconds even though they represent the same amount of elapsed time.
These types of spans are unbalanced.
When a span like 1 second 2000 milliseconds is ISO 8601 serialized,
it's turned into PT3s because there simply is no way to represent
greater-than-second durations in smaller-than-second units in the ISO
8601 duration format. So when PT3s is deserialized, Jiff of course has
no idea that 1 second 2000 milliseconds was actually intended, and
thus treats it as 3 seconds.
On top of this, Jiff imposes fairly strict limits on the individual
units of a Span. Other than nanoseconds, every individual unit can
express the full range of time supported by Jiff (-9999-01-01 through
9999-12-31) and nothing more. So if one serializes a span to the ISO
8601 format with large millisecond, microsecond or nanosecond
components, those have to be folded into the larger hour, minute or
second units. This in turn can create a ISO 8601 duration whose hour,
minute and second units exceed Jiff's unit limits. So in order to
preserve the ability to at least roundtrip all Jiff spans (even if the
individual unit values are lost), Jiff will automatically rebalance
these "larger" units into smaller units at parse time.
This is a big complicated mess and it turns out I got one part of this
wrong: I was only re-balancing units at parse time when we parsed a
fractional component. But in fact, we should be re-balancing spans even
when there isn't a fractional component. Namely, the milliseconds,
microseconds and nanosecond components can add up to a whole number of
seconds, resulting in a whole number of seconds in the corresponding ISO
8601 duration.
This bug was found by @addisoncrump's fuzzer. Nice work.
Because Jiff spans (like Temporal durations) represent each unit individually, and because ISO 8601 require the use of fractional seconds to represent sub-second units, there is an inherent loss of fidelity when spans are serialized to the ISO 8601 duration format.
For example, a Jiff span like
1 second 2000 millisecondsis distinct from3 secondseven though they represent the same amount of elapsed time. These types of spans are unbalanced.When a span like
1 second 2000 millisecondsis ISO 8601 serialized, it's turned intoPT3sbecause there simply is no way to represent greater-than-second durations in smaller-than-second units in the ISO 8601 duration format. So whenPT3sis deserialized, Jiff of course has no idea that1 second 2000 millisecondswas actually intended, and thus treats it as3 seconds.On top of this, Jiff imposes fairly strict limits on the individual units of a
Span. Other than nanoseconds, every individual unit can express the full range of time supported by Jiff (-9999-01-01through9999-12-31) and nothing more. So if one serializes a span to the ISO 8601 format with large millisecond, microsecond or nanosecond components, those have to be folded into the larger hour, minute or second units. This in turn can create a ISO 8601 duration whose hour, minute and second units exceed Jiff's unit limits. So in order to preserve the ability to at least roundtrip all Jiff spans (even if the individual unit values are lost), Jiff will automatically rebalance these "larger" units into smaller units at parse time.This is a big complicated mess and it turns out I got one part of this wrong: I was only re-balancing units at parse time when we parsed a fractional component. But in fact, we should be re-balancing spans even when there isn't a fractional component. Namely, the milliseconds, microseconds and nanosecond components can add up to a whole number of seconds, resulting in a whole number of seconds in the corresponding ISO 8601 duration.
This bug was found by @addisoncrump's fuzzer. Nice work.
Fixes #59