Normative: Check for invalid epoch nanoseconds in Temporal.TimeZone.prototype.get{Next,Previous}Transition

[anba]

GetIANATimeZoneNextTransition and GetIANATimeZonePreviousTransition
aren't required to return an epoch nanoseconds value which is within the
supported range, therefore we have to call IsValidEpochNanoseconds
before invoking CreateTemporalInstant.

[codecov]

Codecov Report

Merging #2311 (ebb098a) into main (d96e662) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #2311   +/-   ##
=======================================
  Coverage   91.08%   91.08%           
=======================================
  Files          19       19           
  Lines       10566    10566           
  Branches     1695     1695           
=======================================
  Hits         9624     9624           
  Misses        932      932           
  Partials       10       10           

Flag	Coverage Δ
test262	83.94% <ø> (ø)
tests	81.83% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d96e662...ebb098a. Read the comment docs.

[Ms2ger]

I might have gone for returning null, but either way it doesn't really matter.

[ptomato]

We could also define the GetIANATimeZone...Transition ops so that they guarantee not to return an out-of-range time and return null instead. That seems more in line with what e.g. SystemUTCEpochNanoseconds does; it clamps the value to the range. Clamping wouldn't be appropriate here, I think, but returning null would. We did receive guidance specifically during the Stage 3 reviews of this proposal not to throw, so it seems in any case that we shouldn't throw here either.

[anba]

I think both options are probably fine. There's a slight semantic difference:

1. Throwing an error indicates that there's another transition, but we can't represent it.
2. Whereas returning null means there are no further transitions.

Returning null allows to write more concise code, though:

let instant = startInstant;
while (instant !== null) {
  // Use `instant`.

  instant = tz.getNextTransition(instant);
}

When an error is thrown, we'd need to wrap the call into a try-catch block:

let instant = startInstant;
while (instant !== null) {
  // Use `instant`.

  try {
    instant = tz.getNextTransition(instant);
  } catch {
    instant = null;
  }
}

But then again going through all transitions seems a rather unlikely case to happen in practice.

[justingrant]

IMO we should not throw an errors for built-in time zones like this. The system is supposed to be reliable! So I'd definitely recommend null in this case.

Or should we go further and add an assertion that the implementation must not return out-of-range values from built-in time zone implementations?

[ptomato]

Meeting 2022-07-07: we should prevent the internal GetIANATimeZone{Previous,Next}Transition operations from returning epoch nanoseconds that are out of range. Therefore I will close this PR and open a new one that fixes the issue that way.

[ptomato]

→ #2351