[apple][HybridGlobalization] Enable more System.Globalization.Tests for Apple Hybrid-Globalization

[matouskozak]

There are a lot of tests in System.Globalization.Tests that are only enabled for Hybrid-Globalization on Browser. For example:

runtime/src/libraries/System.Runtime/tests/System.Globalization.Tests/DateTimeFormatInfo/DateTimeFormatInfoLongDatePattern.cs

Lines 219 to 224 in 71a7d88

	[ConditionalTheory(typeof(PlatformDetection), nameof(PlatformDetection.IsHybridGlobalizationOnBrowser))]
	[MemberData(nameof(LongDatePattern_Get_TestData_HybridGlobalization))]
	public void LongDatePattern_Get_ReturnsExpected_HybridGlobalization(DateTimeFormatInfo format, string expected)
	{
	Assert.Equal(expected, format.LongDatePattern);
	}

Some of these tests could be used to verify correct functionality of Apple Hybrid-Globalization.

---

cc: @mkhamoyan

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-globalization
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

Tagging subscribers to 'os-ios': @steveisok, @akoeplinger, @kotlarmilos
See info in area-owners.md if you want to be subscribed.

[mkhamoyan]

I wonder why are these test cases runtime/src/libraries/System.Runtime/tests/System.Globalization.Tests/DateTimeFormatInfo/DateTimeFormatInfoLongDatePattern.cs enabled for only hybrid mode on browser, maybe they are specific to browser hybrid mode flow @ilonatommy ?
If they are general let's enable for all platforms for both using ICU or hybrid mode.

[ilonatommy]

If they are general let's enable for all platforms for both using ICU or hybrid mode.

They are not specific to hybrid but testing ICU on this is not necessary, in ICU if we loaded the data and it's available for one specific locale, then we can assume all the remaining locales are correct.
In hybrid it's not the case, when for one locale JS can have a correct value, for another one it might return nonsense, especially for DatePatterns where we perform regexing and string operations + JS reply might differ between versions of hosts. A good example is this PR: #90881 where culture-info.ts required changes for ja-JP only and it was caught by these tests. Running them on ICU is in my opinion a waste of testing machine time.

Edit:
For apple I would ask myself a question: is it possible that only few locales are broken while en-US (or some other EFIGS locale) that we most frequently test by default returns correct value? If it is, then enabling them on apple makes sense. Otherwise, one locale per API for apple.

[mkhamoyan]

They are not specific to hybrid but testing ICU on this is not necessary, in ICU if we loaded the data and it's available for one specific locale, then we can assume all the remaining locales are correct. In hybrid it's not the case, when for one locale JS can have a correct value, for another one it might return nonsense, especially for DatePatterns where we perform regexing and string operations + JS reply might differ between versions of hosts. A good example is this PR: #90881 where culture-info.ts required changes for ja-JP only and it was caught by these tests. Running them on ICU is in my opinion a waste of testing machine time.

Edit: For apple I would ask myself a question: is it possible that only few locales are broken while en-US (or some other EFIGS locale) that we most frequently test by default returns correct value? If it is, then enabling them on apple makes sense. Otherwise, one locale per API for apple.

For Apple there should not be broken locales (Apple also uses ICU libs). IMHO running same suite of tests that we were validating ICU should be enough for Apple hybrid mode.

[matouskozak]

They are not specific to hybrid but testing ICU on this is not necessary, in ICU if we loaded the data and it's available for one specific locale, then we can assume all the remaining locales are correct. In hybrid it's not the case, when for one locale JS can have a correct value, for another one it might return nonsense, especially for DatePatterns where we perform regexing and string operations + JS reply might differ between versions of hosts. A good example is this PR: #90881 where culture-info.ts required changes for ja-JP only and it was caught by these tests. Running them on ICU is in my opinion a waste of testing machine time.
Edit: For apple I would ask myself a question: is it possible that only few locales are broken while en-US (or some other EFIGS locale) that we most frequently test by default returns correct value? If it is, then enabling them on apple makes sense. Otherwise, one locale per API for apple.

For Apple there should not be broken locales (Apple also uses ICU libs). IMHO running same suite of tests that we were validating ICU should be enough for Apple hybrid mode.

I think that for Apple, we won't have a problem that locale is missing or is broken. However, for ICU Globalization we have to normalize the retrieved values from ICU using NormalizeDatePattern

runtime/src/libraries/System.Private.CoreLib/src/System/Globalization/CalendarData.Icu.cs

Line 261 in 825bc44

private static string NormalizeDatePattern(string input)

and I believe the same might be needed for Apple hybrid mode (or we should verify that it is not needed at least).

[ilonatommy]

@tarekgh, we are trying to understand what was the motivation for skipping some types of tests for globalization methods when developing the libs. E.g. LongDatePattern that was not tested even though we are performing normalization on our side in the libs.
What's more, we are trying to figure out what is the motivation for testing only specific locales. E.g. en-US, fr-FR (

runtime/src/libraries/System.Runtime/tests/System.Globalization.Tests/DateTimeFormatInfo/DateTimeFormatInfoFirstDayOfWeek.cs

Line 11 in 71a7d88

public static IEnumerable<object[]> FirstDayOfWeek_Get_TestData()

but skipping the rest and how did we choose which ones are worth testing?

[tarekgh]

@ilonatommy we are trying to make the tests stable. The globalization data is changing almost every release of ICU/Windows. If we test all cultures that will make the test unstable. So, we choose subset of the cultures that are stable enough to test against.