Intl.durationFormat is at stage 2

"microseconds" and "nanoseconds" aren't sanctioned units for Intl.NumberFormat,
so we know have to differentiate between supported and sanctioned units.

ICU doesn't provide a public API to retrieve the time separator, so we have
to read it manually from the resource bundles.

Depends on D152743

Implements the Intl.DurationFormat constructor, including the
resolvedOptions() and supportedLocalesOf() methods.

Depends on D152744

Depends on D152745

Depends on D152746

Depends on D152747

Depends on D152748

Depends on D152749

The proposal has been decoupled from Temporal, so this bug no longer depends on bug 1519167.

The proposal itself is at stage 3, but there are still multiple open issues which may require a different implementation approach, e.g. formatToParts is likely to change, see https://github.com/tc39/proposal-intl-duration-format/issues/55. So maybe we should wait a bit longer until the major open issues have been resolved.

When writing the patches, I had to resort to hacks at two points:

1. Formatting microseconds and nanoseconds units through Intl.NumberFormat isn't currently possible, so I had to bypass the check for valid unit identifiers. https://github.com/tc39/ecma402/issues/702 should help to avoid this hack.
2. I had to be creative in formatToParts when digital formatting is used (e.g. "02:00:00.123"). The aforementioned formatToParts changes may require more hacks around Intl.ListFormat.

I've updated the WIP patches to match the current spec proposal text. Not quite yet ready for review, because there are still some open PRs which should land first.

There was an update about this proposal in the ECMA-402 meeting today. Ujjwal thinks that the remaining issues have been addressed that would block implementation here. Anba, does that sound right to you? Is there any feedback you'd like me to share with TG2?

I can look into it. DurationFormat requires NumberFormat v3, which is currently only available in Nightly. I've prepared some patches to enable it by default, but realised too late that you're already assigned to bug 1795756. I hope you don't mind me stealing that bug.

(In reply to Dan Minor [:dminor] from comment #11)

Ujjwal thinks that the remaining issues have been addressed that would block implementation here. Anba, does that sound right to you? Is there any feedback you'd like me to share with TG2?

I've filed the following issues on the proposal bug tracker:

• Editorial: https://github.com/tc39/proposal-intl-duration-format/issues/151
• Editorial: https://github.com/tc39/proposal-intl-duration-format/issues/152
• Editorial: https://github.com/tc39/proposal-intl-duration-format/issues/154
• Normative: https://github.com/tc39/proposal-intl-duration-format/issues/155
• Normative: https://github.com/tc39/proposal-intl-duration-format/issues/156
• Normative: https://github.com/tc39/proposal-intl-duration-format/issues/157

In addition to that, there are the following open PRs:

• Normative: https://github.com/tc39/proposal-intl-duration-format/pull/150
  • I've found two issues with the current PR.
• Editorial: https://github.com/tc39/proposal-intl-duration-format/pull/134 and https://github.com/tc39/proposal-intl-duration-format/pull/143
  • The PartitionDurationFormatPattern abstract operation isn't quite correct, the two PRs aim to fix it in different ways. For example when strictly following the current PartitionDurationFormatPattern definition, formatting {hours:12, minutes:30, seconds:45} with the "digital" style returns the string "12, :, 30, :, & 45" instead of "12:30:45". So we have to guess/interpret how the abstract operation should have been defined. This isn't strictly a blocker for implementations, but definitely a blocker for stage 4.