Justin Grant

From https://github.com/tc39/proposal-temporal/issues/782, there are two generalized categories of use cases for multi-unit relative date/time formatting: > * 8.2.2 Relative to now - e.g. "1 day and 12 hours ago" or...

> For example, `Intl.DateTimeFormat` should support the calendar systems returned by `Intl.supportedValuesOf("calendar")`, no more, no less. For time zones, what you describe is not the current behavior. `Intl.supportedValuesOf("timeZone")` returns only...

> requiring the host hook always return the same values across calls? FWIW, similar language is already part of https://tc39.es/proposal-temporal/#sup-availablenamedtimezoneidentifiers and https://tc39.es/proposal-temporal/#sup-availablenamedtimezoneidentifiers.

I just pushed a new commit that includes what I think resolves all review feedback. @gibson042 @sffc (and anyone else who's interested) do you want to re-review?

> If you want to update StringSplitToList to support empty-string _S_ (with result in alignment with String.prototype.split, e.g. « **""** »), I would not be opposed. But dealing with it...

> I think this PR should be ready to merge. Actually, I assume we want Test262 tests for this new text. I'll start working on those. And of course it...

> On second thought, let's save the IsWellFormedUnitIdentifier changes for a followup. OK, I reverted that part. I think this PR should be ready to present at Helsinki, unless there's...

AFAIK this is ready to merge. It lacks Test262 tests, but I assume these can be added later?

Clarifying @ptomato's comment above: this U+2212 character is currently only exposed via Temporal, because the only way an offset can get into `Date` is via SystemTimeZoneIdentifier which AFAIK is required...

I rebased to latest main. Hopefully ready to merge?