Another Temporal update

• We continue to adjust the proposal based on implementor feedback and bug reports
• Fixes continue to become more and more obscure edge cases
• Acknowledge new concerns about mathematical values in Temporal.Duration and are considering how to address
• Good news from the IETF

IETF update: "IXDTF"

• Draft syntax for calendar annotations has reached consensus in IETF SEDATE working group
• Tentatively named IXDTF (Internet Extended Date-Time Format)
• Only administrative blockers remain
  • (standards organizations, amirite?)
  • We will continue to push, and alert the plenary when this happens

Implement conclusions of IXDTF (PR #2397)

• IXDTF contains a specification of our proposed calendar annotation, as well as the de-facto standard time zone annotation introduced by Java
• Also allows other (as yet unknown) annotations: 2022-09-13T10:00[Asia/Tokyo][magic=happens]
• Introduces a "critical flag" indicating that an annotation must be respected: 2022-09-13T10:00[!Asia/Tokyo]

Implement conclusions of IXDTF (2)

• Temporal only recognizes time zone and calendar annotations, and ignores unknown ones unless they are marked critical
• Time zone and calendar annotations were already treated as critical anyway, so the critical flag has no effect in Temporal
  • i.e. 2022-09-13[u-ca=hebrew] would already never return a date in the Gregorian calendar
  • However, flag may have meaning to other consumers of ISO strings

Implement conclusions of IXDTF (3)

• For interoperability with other consumers, add a new value "critical" to the timeZoneName and calendarName options in the various toString() functions:

Temporal.Now.zonedDateTimeISO()
  .toString({ calendarName: 'critical', timeZoneName: 'critical' });
// returns:
// "2022-09-12T19:00-07:00[!America/Vancouver][!u-ca=iso8601]"

ISO 8601 grammar (PRs #2394, #2395)

Several other tweaks:

• A string of 8 decimal digits is a valid (but not currently existing) calendar name and also valid YYYYMMDD syntax.
  • Does Temporal.Calendar.from('20220912') throw due to no calendar with that name existing, or return the date 2022-09-12's ISO 8601 calendar? We picked the latter
• Make time zone and calendar names case-insensitive, as they currently are in ECMA-402

ISO 8601 grammar (2)

Several other tweaks:

• Fix bug where interpreting a relativeTo string as a PlainDate would accept a Z UTC designator (which PlainDate does not)
• Allow annotations after MM-DD and YYYY-MM syntax
  • (PR #2398 proved controversial during review period; withdrawn from this plenary)

Tweaks to observable operations (PR #2377)

• Follow conventions for order of observable operations in calendars' dateFromFields, yearMonthFromFields , monthDayFromFields methods
• Affects nothing unless you are going out of your way to spy on operations with Proxy traps or suchlike

Validation of returns from user code (PR #2387)

• When calling a calendar's dateAdd() implemented in user code, throw if we detect an inconsistent result
  • (technical details: in our abstract operation NanosecondsToDays, validate that the results from AddZonedDateTime are self-consistent)

Remove unnecessary property access (PR #2392)

• Skip an unnecessary observable HasProperty operation when calling from() on an object that already has the correct internal slot

const calendarInstance = new Temporal.Calendar('iso8601');
Temporal.Calendar.from(calendarInstance);
// would previously do HasProperty(calendarInstance, 'calendar')

const timeZoneInstance = new Temporal.TimeZone('UTC');
Temporal.TimeZone.from(timeZoneInstance);
// would previously do HasProperty(timeZoneInstance, 'timeZone')

Fix rounding in Instant arithmetic (PR #2400)

• Latent bug in the spec text, exposed by the adoption of NumberFormat V3's rounding modes
• Result of Temporal.Instant.prototype.until() was rounded as if it were a number of epoch nanoseconds, not a Duration
• Ditto for Temporal.Instant.prototype.since()
• The intention was already correctly tested in test262, so this brings the spec text in line with that

Critical flag discussion

• After Day 1 of plenary, we discussed and resolved blocking issues
• All parties OK to proceed with the normative change as originally presented

Outcome

• To maximize compatibility with Java and other legacy libraries, default output of toString doesn't include !
• Critical flag is available as opt-in option to toString
• A web-compatible follow-up proposal (e.g. new read-only property, separate parsing method, etc.) can be made to add the ability to detect presence of ! in input strings, so that users can take that info and vary the output of toString if needed
• Whether that proposal is needed will depend on use cases for ! that may appear

Requesting consensus

On PR #2397

Recap of what it does:

• Bring syntax of annotations in line with IXDTF
• Enable the toString option noted in the previous slide
• Throw if unknown annotations with the critical flag are parsed