Progress update

• Implementation continues; large Firefox patchset under review
• Only one change from March is outstanding: integer arithmetic optimization
• No other big changes expected
  • Issues reported since March have been minor

IETF standardization progress (#1450)

• Steering group review prompted one change that affects us
  • (More details in the second section of the presentation)
• Review continues

Integer arithmetic progress

• Solution framework remains largely the same as discussed in March
• A few changes necessary:
  • Upper bound placed on the total of days...nanoseconds (instead of hours...nanoseconds)
  • (Possibly) bound years, months, and weeks individually

Deduplication of field names (PR #2570)

• Request from Anba (Firefox) for a small optimizability improvement
• Removes throws on duplicate property names in PrepareTemporalFields
• Also throws on property names constructor and __proto__
• Unlikely edge case, unless intentional with a custom calendar

const calendar = new class extends Temporal.Calendar {
  fields(fieldNames) { return super.fields(fieldNames).concat(['monthCode', 'monthCode']); }
}('iso8601');

const ym = new Temporal.PlainYearMonth(2023, 3, calendar);
ym.toPlainDate({day: 1});
// Current spec: monthCode property was accessed thrice.
// After this change: throws a RangeError.

Fix rounding bug (PR #2571)

• Bug reported by Adam Shaw (a polyfill author)
• In cases where a number is rounded up to next unit, current behaviour is inconsistent with Duration.prototype.round()
• Fixes the result after rounding in case of until()/since()/toString()

const earlier = new Temporal.PlainDate(2022, 1, 1);
const later = new Temporal.PlainDate(2023, 12, 25);
const duration = earlier.until(later, { largestUnit: "years", smallestUnit: "months", roundingMode: "expand" });
console.log(duration.toString());
// Current spec text: 1Y12M 
// After this change: 2Y

>1 calendar annotation (PR #2572)

• Required due to a clarification from the IETF on how to interpret multiple calendar annotations
• Also incorporates a suggestion from Anba (Firefox) for better optimizability in YYYY-MM and MM-DD strings

Temporal.PlainDate.from("2000-05-02T15:23[u-ca=iso8601][!u-ca=gregory]");
// Current spec text: Created a PlainDate object with ISO 8601 calendar
// After this change: Throws a RangeError

Temporal.PlainYearMonth.from("2000-05[u-ca=iso8601][u-ca=gregory]");
// Current spec text: Throws a RangeError
// After this change: Creates a PlainYearMonth object with ISO 8601 calendar

Proposed conclusion for the notes

Consensus on making normative changes to:

• improve handling of duplicate names returned from a custom calendar's fields method (PR #2570)
• fix a bug with rounding durations (PR #2571)
• adapt handling of multiple calendar annotations to match the IETF's recent decision (PR #2572)