Implementer concern: When can subdurations lose precision?

[rkirsling]

While I'm pleased about #2094's specifying that Duration fields be f64-representable, this test raises a significant practical concern about "who should be responsible for not losing precision".

In particular:

1. If the difference in nanoseconds between two Instants is not f64-representable, it is actually reasonable to expect that the BalanceDuration call in DifferenceTemporalInstant not be lossy?
2. Preventing loss in this case requires that the implementation of TotalDurationNanoseconds not be an f64 operation. This is a tricky line to walk:
   • The general case of adding two Duration fields must be an f64 operation, otherwise what have we gained by storing them as such?
   • It may still be logical to say that "summing all the fields together for rebalancing should not be subject to loss during the calculation". This just gets a bit funky in RoundDuration steps 6 and 7, where rounding to a date unit uses TotalDurationNanoseconds but rounding to a time unit does some direct (non-integral) addition.

[ptomato]

Thanks, this is good feedback. We'll discuss it in our next champions meeting. You are welcome to join in, but in the meantime do you have any potential solutions in mind? (e.g. do the balance arithmetic in the f64 domain)

[rkirsling]

Thanks!

At first I was thinking, "could we just 'fix' the test?", but untested does not mean un(der)specified, so that's a cop-out.

Perhaps a concrete question to focus on here is:
"Should duration.toString() === duration.round('nanoseconds').toString() be an invariant?"

This is nice because it doesn't involve crossing in/out of the world of durations. And we might want to say yes, when considering PT1111111011.111111101S (the duration in the test), where precision loss only occurs at the point of expressing the total duration in nanoseconds. But then subdurations needn't even fit into Int128s—m = 2**129; new Duration(0,0,0,m,m,m,m,m,m,m) still has a finite total—so of course we're forced to say no.

If durations being unbounded implies that TotalDurationNanoseconds cannot avoid precision loss (or integer overflow, which presumably would be worse), then it seems hard to justify DifferenceTemporalInstant as a special case purely because it's crossing into the world of durations anew. Realistically, it's natural for the thing being balanced in BalanceDuration to be an array of doubles.

[justingrant]

To close the loop, there was previous discussion (about putting bounds on the size of Duration fields) that may be relevant to this issue. IMO, the most relevant part of that discussion probably starts with @rkirsling's comment but continues down quite a bit:

Since there doesn't seem to be a precedent for printing the digits of a Number value larger than 10²¹ (the magic number in Number.p.toFixed), this seems like a pretty significant topic in need of discussion.

[rkirsling]

Importantly, balancing logic also occurs in steps 2-7 of TemporalDurationToString. This is an even worse situation than DifferenceTemporalInstant because it goes beyond f64-representability into f64-storability.

Namely, the spec currently suggests that Temporal.Duration.from({ microseconds: Number.MAX_VALUE, nanoseconds: Number.MAX_VALUE }).toString() should somehow manage to display seconds as a decimal number, even though this is Infinity in the f64 domain. It's unfortunate enough to need to use BigInt#toString instead of Number#toString to display numbers beyond Number.MAX_SAFE_INTEGER, but repeating what I said in the issue description, if we're not even allowed to add two subdurations in the f64 domain, then we've gained nothing by storing f64s. I'll plan to implement this particular case as a RangeError for now.

[ptomato]

Addressed thoroughly by #2727.

[ptomato]

We believe this is addressed now. Duration units are specified to have upper bounds such that it should be possible to do all calculations using 84-bits of integer math (e.g., i128 or i64+i32) or two f64s.