Need to define which option values are supported in Intl methods with null locale

[justingrant]

The readme says:

The "localized" output for "und" should avoid including actually localized text in its output, such as fully written-out unit names or the names of months.

The proposal should define:

• Which option values (or entire options) of Intl formatting methods are not supported.
• What should happen if a user provides a not-supported option value. If the answer is "each unsupported value has a fallback value that will be used instead" then that fallback value should be defined.

I assume that options like timeZone, calendar, and fractionalSecondDigits *will* be supported because they affect the non-localized numeric values of the output. If this assumption is wrong, please explain why. Thanks!

[eemeli]

First of all, I rather like null as an explicit value for this "locale", rather than a string identifier. Atm using it produces a TypeError.

Which option values (or entire options) of Intl formatting methods are not supported.

I'm not sure yet. This also depends on what's meant by "not supported": do they not have an effect on the output, or do they produce an error? I don't think any current options should necessarily produce errors, but some may not have any effect.

What should happen if a user provides a not-supported option value. If the answer is "each unsupported value has a fallback value that will be used instead" then that fallback value should be defined.

I would actually go even further, and not just define the exact behaviour for option values, but also the output that's produced.

I assume that options like timeZone, calendar, and fractionalSecondDigits will be supported because they affect the non-localized numeric values of the output. If this assumption is wrong, please explain why. Thanks!

That sounds reasonable. I'm not very familiar with other calendars than Gregorian; do others also have standardised ways of displaying dates?

[justingrant]

First of all, I rather like null as an explicit value for this "locale", rather than a string identifier. Atm using it produces a TypeError.

Oh, interesting. I opened #5 for this idea.

I was actually just using null colloquially to refer to this locale. I'm not convinced that this is the right term for it unless #5 is accepted, which I'm undecided is a good idea or not. If #5 is not accepted, then I think we should pick another name. See #6.

I would actually go even further, and not just define the exact behaviour for option values, but also the output that's produced.

Agreed. For Intl.DTF formats in this proposal's locale, one possibility would be to align to Temporal objects' toString output. I opened #7 to discuss.

[justingrant]

I assume that options like timeZone, calendar, and fractionalSecondDigits will be supported because they affect the non-localized numeric values of the output. If this assumption is wrong, please explain why. Thanks!

That sounds reasonable. I'm not very familiar with other calendars than Gregorian; do others also have standardised ways of displaying dates?

After thinking about it, I'm not sure that supporting the calendar option would be a good idea or not. See #9 to discuss.