Allow to modify the numbering system through "nu"?

[anba]

V8 currently allows, contrary to the spec proposal, to modify the numbering system of the Intl.RelativeTimeFormatter.

For example new Intl.RelativeTimeFormat("en-u-nu-thai").format(1, "hour") returns "in ๑ hours" in V8 even though the current proposal requires to ignore "nu" and instead to return "in 1 hour".

---

Except that invalid "nu" values may crash V8, so don't try things like new Intl.RelativeTimeFormat("en-u-nu-foo").format(1, "hour") at home. :zipper_mouth_face:

[littledan]

This is a good point. I think we should add this feature. Let's discuss at the next Intl meeting. PRs welcome to help make this more concrete! cc @FrankYFTang

[FrankYFTang]

I think anab raise a good issue and it will be beneficial to clarify in the spec. "v8 currently allows, contrary to the spec proposal, to modify the numbering system of the Intl.RelativeTimeFormatter." - I do not see anywhere in the current proposal DISALLOW the use of "nu" in the locale, so I do not understand why you state it is "contrary to the spec proposal" HOW the object in each locale to format the date is not part of the proposal, from my understanding.

[zbraniecki]

I do not see anywhere in the current proposal DISALLOW the use of "nu" in the locale, so I do not understand why you state it is "contrary to the spec proposal" HOW the object in each locale to format the date is not part of the proposal, from my understanding.

I also don't see anything that would limit us to any particular numerical system. I think we should support nu UE and numberingSystem (in line with adding it to the `Intl.NumberFormat).

[anba]

ResolveLocale strips away any unsupported Unicode extension keys, so when InitializeRelativeTimeFormat calls it with an empty list for the relevantExtensionKeys parameter, the returned [[Locale]] (and [[DataLocale]]) no longer have a Unicode extension subtag. And that means the RelativeTimeFormat's internal NumberFormat object (InitializeRelativeTimeFormat, step 19) will always be created with a locale which no longer contains "nu".

[gsathya]

@anba is correct, nu should be ignored. V8 7.1 works fine; the nightly build has a known bug that should be fixed soon.

[littledan]

Well, I agree with @gsathya and @anba's interpretation of the current specification, but this doesn't mean that we shouldn't add the feature. It's on the agenda for the next Intl meeting.

[littledan]

OK, we agreed at the November 2018 Intl meeting to follow this option. Will follow up with a spec patch.

[littledan]

Closing due to #99