Should null be accepted in place of the string ID for this locale?

[justingrant]

From #2 (comment):

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.

This seems reasonable, although doing it would mean that code checking the thruthyness of a locale ID would treat the null calendar identically to an un-provided (undefined) calendar option. I suspect this would subtly change behavior of existing code like this:

function doSomethingWithLocale (id) {
  if (!id)  {
    // do something when the user didn't provide a locale
  }
  // . . .
}

For this reason, we'd need to be careful about the tradeoff between the convenience and intuitiveness of using null with the consequence of potentially breaking code like what's above. I don't yet have an opinion about whether this is a deal-breaker or not for using null.

A related question: is null is accepted, then should it be the only value accepted? Or should it also accept a string ID? (Which I suggest in #3 should probably not be existing values like und or zxx.)

• If only null is accepted, then it'd forclose accepting subtags, which may or may not be a problem depending on how Should subtags be accepted? #4 is resolved.
• If a string ID is also accepted, then should new Intl.DateTimeFormat().resolvedOptions().locale return null or the string ID?

(edited to fix code sample and my mistakes above)

[eemeli]

This seems reasonable, although doing it would mean that code checking the thruthyness of a calendar would treat the null calendar identically to an un-provided (undefined) calendar option.

Could you explain how accepting null as a locale identifier would have an effect on calendar values? I don't see how those are related.

[justingrant]

Could you explain how accepting null as a locale identifier would have an effect on calendar values? I don't see how those are related.

Whoops, that was a copy/paste error from another draft issue. I just edited the OP to clarify what I intended, which was about locale IDs not calendar IDs. Thanks for pointing out my mistake!

[eemeli]

Thank you for the correction, now I understand your concern a bit better. :)

I'm starting to think that the answer to your titular question should be "yes", but with a canonicalizzation from null to 'zxx'. This would let resolvedOptions().locale continue to always be a string, and would permit subtags with the zxx base locale. As I explain in #3 (comment), it is not a currently supported locale identifier.

Users with code as you describe could also explicitly use 'zxx' to avoid such issues. Accepting null would be an affordance for developers, because zxx is rather intentionally weird.