Audit of user code calls, part 3 #2671

…o ZDT We call AddZonedDateTime in several places with all of the duration components being zero except for days. In this case, we can skip the calendar operations altogether, because adding/subtracting days to/from the ISO fields is not calendar-dependent.

In the case where AddZonedDateTime is called with years, months, and weeks all zero, we can fall back to AddDaysToZonedDateTime to avoid the calendar call, and then AddInstant on the result. In BalancePossiblyInfiniteTimeDurationRelative, inline the fast path from AddZonedDateTime since we are not adding years, months, or weeks, and can now no longer call any calendar methods. Give all intermediate objects the ISO 8601 calendar for simplicity.

…o PlainDate In a few places, we called CalendarDateAdd with a days-only duration. For days-only, it's not necessary to consult the calendar: we can just add the days in the ISO calendar space to the ISO calendar values in the internal slots. (also fixes a rebase error with truncate(_fractionalDays_)) Closes: #2685

Introduce an operation AddDate, which has a fast-path through the ISO calendar in the case where we would otherwise call calendar.dateAdd() with years, months, and weeks all zero.

If two Temporal objects have identical internal slots, then we can skip calculating the difference with a calendar method; the difference is always 0. This optimization isn't necessary for PlainTime or Instant differences, since no calendar methods are called for those. Implementations can return early for PlainTime or Instant if they like, but it won't be reflected in the spec text in order to keep things as simple as possible. Note that the early return still comes after the processing of the options object. Passing an illegal options object to until() or since() should still throw, even if the difference is zero. (We'll also fast-path CalendarDateUntil, but this fast path also cuts out calls to calendar.dateFromFields().)

Introduce an operation DifferenceDate, which has a fast-path through the ISO calendar (via DaysUntil) in the case where we would otherwise call calendar.dateUntil() with largestUnit === "day". Also return a blank duration immediately if the two dates are the same day. Note that this makes it impossible for the following BalanceDuration call in DifferenceISODateTime to throw. The dateUntil() method will no longer be called for largestUnits of "day" or less. So dateDifference.[[Days]] can be at most Number.MAX_VALUE, but timeDifference cannot balance into more than one day and make it overflow in the BalanceDuration call. In NanosecondsToDays, inline the fast path from DifferenceISODateTime since we only have largestUnit === "day" there and can now no longer call any calendar methods. Give all intermediate objects the ISO 8601 calendar for simplicity. Note, as evident from the corresponding test262 tests, this removes several loopholes where it was possible to return particular values from user calls that would cause infinite loops, or calculate zero-length days.

…mbiguous datetime In DisambiguatePossibleInstants, when getPossibleInstantsFor has returned an empty array, we calculate the UTC offset in the time zone one day before and one day after. Don't look up the method twice when doing this. Similarly, in InterpretISODateTimeOffset, when getPossibleInstantsFor has returned more than one possibility, we compare the offset nanoseconds of each possibility. Also don't look up the method twice when doing this.

There are a few more places where we can avoid doing an additional lookup and call of getOffsetNanosecondsFor on the same ZonedDateTime, to convert it into a PlainDateTime. This affects - Temporal.Duration.prototype.add (with relativeTo ZonedDateTime) - Temporal.Duration.prototype.subtract (ditto) - Temporal.Duration.prototype.round (ditto) - Temporal.Duration.prototype.total (ditto) - Temporal.ZonedDateTime.prototype.since - Temporal.ZonedDateTime.prototype.until (also fixes "and" vs "or" prose mistakes) Closes: #2680 Closes: #2681

Fix for bug in User Code Calls Part 2 (51ea969), spotted by Anba. Thanks! The existing code forgot to take negative durations into account. Closes: #2679

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Audit of user code calls, part 3 #2671

Audit of user code calls, part 3 #2671

Commits on Oct 4, 2023