ResolveLocale accepts requests for arbitrary locale identifiers, and in the event of a match propagates relevant keywords into the result for use and recombination downstream. For example, Intl.DateTimeFormat [[RelevantExtensionKeys]] is « "ca", "hc", "nu" » while Intl.NumberFormat [[RelevantExtensionKeys]] is « "nu" », so requesting locale "en-US-u-ca-hebrew-nu-arab" with the former resolves to "en-US-u-ca-hebrew-nu-arab" and with the latter resolves to "en-US-u-nu-arab".
But when there are no requested locales or they fail to match, the DefaultLocale() fallback result is forbidden to include a Unicode locale extension sequence. In practice, implementations don't fully conform with this requirement—JavaScriptCore maps an LC_ALL=C environment into default locale "en-US-u-va-posix" as noted at tc39/test262#615 and tc39/test262#5125, and on my locale Linux machine I can get V8 new Intl.DateTimeFormat().resolvedOptions().locale to return a value like "en-US-u-ca-hebrew".
The divergent behavior isn't unreasonable, either... it makes sense that an implementation could have useful context for more specificity than just language, script, region, and variant. And of the two sites where DefaultLocale is used, TransformCase uses the result for locale lookup (which already tolerates extension sequences) and ResolveLocale uses it as a fallback for output from locale lookup (i.e., where extension sequences could have been returned but were not).
So, while noting that it would be a normative change with the possibility of breaking code that calls an Intl constructor to extract the default locale via resolvedOptions() and then blindly appends "-u-…" as in the tests mentioned by tc39/test262#615, I'd like to pursue this.
ResolveLocale accepts requests for arbitrary locale identifiers, and in the event of a match propagates relevant keywords into the result for use and recombination downstream. For example, Intl.DateTimeFormat [[RelevantExtensionKeys]] is « "ca", "hc", "nu" » while Intl.NumberFormat [[RelevantExtensionKeys]] is « "nu" », so requesting locale "en-US-u-ca-hebrew-nu-arab" with the former resolves to "en-US-u-ca-hebrew-nu-arab" and with the latter resolves to "en-US-u-nu-arab".
But when there are no requested locales or they fail to match, the DefaultLocale() fallback result is forbidden to include a Unicode locale extension sequence. In practice, implementations don't fully conform with this requirement—JavaScriptCore maps an
LC_ALL=Cenvironment into default locale "en-US-u-va-posix" as noted at tc39/test262#615 and tc39/test262#5125, and on my locale Linux machine I can get V8new Intl.DateTimeFormat().resolvedOptions().localeto return a value like "en-US-u-ca-hebrew".The divergent behavior isn't unreasonable, either... it makes sense that an implementation could have useful context for more specificity than just language, script, region, and variant. And of the two sites where DefaultLocale is used, TransformCase uses the result for locale lookup (which already tolerates extension sequences) and ResolveLocale uses it as a fallback for output from locale lookup (i.e., where extension sequences could have been returned but were not).
So, while noting that it would be a normative change with the possibility of breaking code that calls an Intl constructor to extract the default locale via
resolvedOptions()and then blindly appends "-u-…" as in the tests mentioned by tc39/test262#615, I'd like to pursue this.