Relative Date Time Format fails with locale en-US and non-Latn numbering system

[sven-oly]

In ICU conformance testing with this data, the expected result has Arabic digits. This appears to be a problem in inheritance for en-US

{"test_type": "rdt_fmt", "label":"704","unit":"second","count":"-100","locale":"en-US","options":{"numberingSystem":"arab"}}

Actual result: {"actual_options":"DataLocale{en-US-u-nu-arab}","label":"704","result":"100 seconds ago"}

Expected "١٠٠ seconds ago"

Similar with Bengali digits:
{"test_type": "rdt_fmt", "label":"1056","unit":"second","count":"-100","locale":"en-US","options":{"numberingSystem":"beng"}}

Actual result: {"actual_options":"DataLocale{en-US-u-nu-beng}","label":"1056","result":"100 seconds ago"}

Expected: "১০০ seconds ago"

Similar with Adlam digits:
{"test_type": "rdt_fmt", "label":"1408","unit":"second","count":"-100","locale":"en-US","options":{"numberingSystem":"adlm"}}

Actual result: {"actual_options":"DataLocale{en-US-u-nu-adlm}","label":"1408","result":"100 seconds ago"}

Expected: "𞥑𞥐𞥐 seconds ago"

[sffc]

I think it's FixedDecimalFormatter in general, not just RelativeTimeFormatter.

-u-nu-arab only loads data for locales that have a -u-nu-arab. However, not all locales have it, and datagen only exports it when it is in the CLDR data for that locale.

It does raise the question, do we really want/need to support en-u-nu-arab if CLDR doesn't provide data for it? ICU and others support arbitrary numbering systems with Latin symbols. But does that make sense?

[sven-oly]

I agree that we should verify if using any numbering system with any locale is useful. The tests show that Arabic, Adlam, and Bengali digits do appear with conforming locales.