Backport #4163 to 4.x: Intl.Locale getWeekInfo picks its region through RegionPreference

[lahma]

Backports #4163 (commit ad440908afe557a2bab81c9420d60753b83d62d3) to 4.x.

Base: 4.x at 6b39fa0760d700ce13180ed9ee0a250b082d19c3.

What it fixes

Intl.Locale.prototype.getWeekInfo read CLDR's week data for the tag's region subtag and nothing else. A tag without a region subtag therefore got the world's week (001), and the -u-rg- and -u-sd- keywords were ignored.

It now picks the region the way RegionPreference and WeekInfoOfLocale do, in this order:

1. a -u-rg- override, if CLDR has week data for it
2. the region subtag
3. a -u-sd- subdivision's region
4. the region Add Likely Subtags supplies
5. 001

Both firstDay and weekend are read for that region. A -u-fw- keyword still wins for firstDay.

What changes for a script. Both new answers are what the specification and every browser give:

new Intl.Locale('en').getWeekInfo().firstDay;                // was 1, now 7: "en" is likely "en-US"
new Intl.Locale('en-US-u-rg-gbzzzz').getWeekInfo().firstDay; // was 7, now 1: the override names Great Britain

What the pick carried and what it did not

file	on 4.x
Jint/Native/Intl/RegionPreference.cs	applied verbatim; stays internal
Jint/Native/Intl/Data/WeekData.cs	applied verbatim (GetLookupRegion, internal)
Jint/Native/Intl/IntlUtilities.cs	applied verbatim: CanonicalizeUnicodeLocaleId goes private → internal, on an internal class
Jint/Native/Intl/LocalePrototype.cs	hand-ported, see the provider rung
Jint/Native/Intl/DefaultCldrProvider.cs	dropped, see the provider rung
Jint.Tests/Runtime/IntlLocaleRegionPreferenceTests.cs	transcribed NUnit → xUnit v3 ([TestCase] → [Theory] + [InlineData], [Test] → [Fact]). Main's two provider tests are dropped (below)
Jint.Tests.Test262/Test262Harness.settings.json	the same four getWeekInfo exclusions are removed. 4.x carried them too, and all four files exist in 4.x's pin 3655e746
Jint.Tests/SpecAnchors.txt, docs/guide/migrating-to-v5.md	dropped; neither file exists on 4.x

The provider rung

On main, getWeekInfo asks the configured ICldrProvider.GetWeekInfo first, and only falls back to the embedded CLDR data when the provider returns null. Main added that in #3357, a v5 change that also removed public members, so it is not on this branch. 4.x's getWeekInfo never asks the provider. It reads the embedded WeekData for locale.Region. The port changes only that lookup, to WeekData.GetLookupRegion(RegionPreference.Of(locale.Locale)). It adds no provider rung.

Main's hunk to DefaultCldrProvider.GetWeekInfo is left out. Nothing in the 4.x engine calls that method, so only a host calling it directly through ICldrProvider can see it. Main changed it because on main that method answers the script. Here it does not. It also already disagrees with the script in another way: it returns a hardcoded Saturday–Sunday weekend for every region, which main fixed in #3357. Fixing only its region would change a public method's answer with nothing in script depending on it, and would leave it half-corrected: "fa" would get Iran's Saturday first day with a Saturday–Sunday weekend. For the same reason, main's two tests that need a provider are not ported. One subclasses DefaultCldrProvider, which is sealed on 4.x, to test the provider rung. The other tests the dropped hunk.

The likely-subtags data

The Add Likely Subtags step reads Data/LikelySubtags.cs / LikelySubtagsData.cs / LikelySubtags.txt. The week lookup reads Data/WeekData.Data.cs / WeekData.txt. The keyword regions are canonicalized through LocaleData. All of these are byte-identical between 4.x and main (git diff upstream/4.x upstream/main -- Jint/Native/Intl/Data/ touches none of them), so no data table comes with this port.

Verification

The ported tests (26 cases) ran first against unfixed 4.x (test file only), then against the fixed tree:

	net10.0	net472
before the fix	13 failed / 13 passed of 26	13 failed / 13 passed of 26 (the same 13)
after the fix	0 failed / 26 passed	0 failed / 26 passed

The four test262 files, each in strict and sloppy mode (8 cases), with the exclusions removed:

• Unfixed (the LocalePrototype lookup reverted to locale.Region): all 8 fail. For example, getWeekInfo() for "en-US-u-rg-dezzzz" should return firstDay that matches the override region Expected SameValue(«7», «1»), and getWeekInfo() for "th" should return firstDay that matches the likely region Expected SameValue(«1», «7»).
• Fixed: all 8 pass, and so do the other 14 getWeekInfo cases (22/22).

Full solution, one dotnet test -c Release run:

project	net10.0	net472
Jint.Tests	7639 passed / 0 failed / 4 skipped	7554 passed / 0 failed / 4 skipped
Jint.Tests.PublicInterface (incl. the public-API snapshot)	1874 passed / 0 failed / 9 skipped	1866 passed / 0 failed / 9 skipped
Jint.Tests.CommonScripts	28 passed / 0 failed	28 passed / 0 failed
Jint.Tests.SourceGenerators	52 passed / 0 failed	n/a
Jint.Tests.Test262 (pin 3655e746)	102,507 passed / 2 failed / 175 skipped (see below)	n/a

The public-API snapshots pass untouched, and no .received file was written. Everything this change touches is internal or private.

test262. Both failures were staging/sm/Array/toSpliced-dense.js, strict and sloppy. Each hit the 30 s timeout under load; this is one of the known load flakes. Re-run alone with --filter "Name~toSpliced-dense.js", both pass in 1 s. The net result is 102,509 passed / 0 failed / 175 skipped. That is the 4.x control's 102,501 / 0 / 183, plus the 8 cases (4 files × strict and sloppy) that the removed exclusions had been skipping.

🤖 Generated with Claude Code

https://claude.ai/code/session_01PanPJbBD7pQC9fRiTpHxvs