I'm new to such a big and complex project and not sure how to test these changes, so this is a draft at the moment. Looking forward to help from anyone.

Example affected patterns:

More information can be found in the fixing issue.

@PopSlime thanks for submitting the PR.
Let's add a test case inhttps://github.com/dotnet/runtime/blob/main/src/libraries/System.Runtime/tests/System.Globalization.Tests/DateTimeFormatInfo/DateTimeFormatInfoLongTimePattern.cs to validate the implemented changes.

/azp run runtime-extra-platforms

@mkhamoyan I'm not sure how to write the test for this because the retrieved time format is device-/platform-dependent.

Instead of testing against some specific patterns, I'm considering adding a test that fails if a 12-hour clock is used without an AM/PM designator in any pattern in any culture. Also we need another test for the unquoted literal texts, which I have no clues how to do yet.

By the way, short time patterns are also affected by this PR.

@PopSlime I was thinking something like below (same test case for shorttime patterns underhere) would validate the change.

[Theory][InlineData("zh-TW")][InlineData("en-US")][InlineData("fr-FR")]public void LongTimePattern_ValidateAMPMDesignators(string cultureName){    var cultureInfo = new CultureInfo(cultureName);    var date = DateTime.Today + TimeSpan.FromDays(10) + TimeSpan.FromMinutes(10);    string formattedDateTime = date.ToString("T", cultureInfo);        Assert.True(formattedDateTime.Contains(cultureInfo.DateTimeFormat.AMDesignator));}

This should be consistent for all platforms and devices.
Now we see issue only in some android devices because of differentCLDR versions.

@mkhamoyan Is it safe to assume those cultures use a 12-hour clock?fr-FR uses a 24-hour clock on my side.

@mkhamoyan Is it safe to assume those cultures use a 12-hour clock?fr-FR uses a 24-hour clock on my side.

My bad,fr-FR shouldn't be there.

How about this?

[Fact]publicvoidLongTimePattern_VerifyTimePatterns(){foreach(varcultureinCultureInfo.GetCultures(CultureTypes.AllCultures)){varpattern=culture.DateTimeFormat.LongTimePattern;varsegments=pattern.Split('\'');booluse12Hour=false;booluseAMPM=false;for(vari=0;i<segments.Length;i+=2){varsegment=segments[i];use12Hour|=segment.Contains('h',StringComparison.Ordinal);useAMPM|=segment.Contains('t',StringComparison.Ordinal);}Assert.True(!use12Hour||useAMPM,$"Bad time pattern for culture{culture.Name}: '{pattern}'");}}

By the way, this fails on my PC (Windows) withmi: 'h:mm:ss' andmi-NZ: 'h:mm:ss'. Should we address this in another issue?

How about this?

Looks good to me.

By the way, this fails on my PC (Windows) withmi: 'h:mm:ss' andmi-NZ: 'h:mm:ss'. Should we address this in another issue?

Yes , we should file an issue for that.
Let's push in the PR and check how it behaves on other platforms.

@dotnet-policy-service agree

By the way, this fails on my PC (Windows) with mi: 'h:mm:ss' and mi-NZ: 'h:mm:ss'. Should we address this in another issue?
Yes , we should file an issue for that.

I don't think we can fix that as the patterns are picked from Windows. I suggest you mark your new test methods with the attribute and see if this can help?

I'll do that, but I also want to see if similar issues are occurring on other platforms, so let's wait for these checks to be done.

this fails on my PC (Windows) with mi: 'h:mm:ss' and mi-NZ: 'h:mm:ss'.

I am trying on my machine, and I am not getting the same results you are getting.

mi-NZ .. Maori (New Zealand) .. h:mm tt .. h:mm:ss ttmi .. Maori .. h:mm tt .. h:mm:ss tt

running code like:

varci=CultureInfo.GetCultureInfo("mi-NZ");Console.WriteLine($"{ci.Name} ..{ci.EnglishName} ..{ci.DateTimeFormat.ShortTimePattern} ..{ci.DateTimeFormat.LongTimePattern}");ci=CultureInfo.GetCultureInfo("mi");Console.WriteLine($"{ci.Name} ..{ci.EnglishName} ..{ci.DateTimeFormat.ShortTimePattern} ..{ci.DateTimeFormat.LongTimePattern}");

What Windows version do you have? I am wondering how you get this result?

It seems that the version of the CLDR data installed on my PC is below 36. The time format formi was fixed inunicode-org/cldr#104.

• Operating system: Windows 10
• Version number: 22H2
• Internal version: 19045.4529

ok, then the attribute

I meant using check likeif (PlatformDetection.ICUVersion.Major >= 68) .

@PopSlime the tests are still failing. For now, can you exclude running this test with hype globalization? or special casefr-CA when encountering it?@ilonatommy@mkhamoyan do you have any better suggestion?@PopSlime already logged issue to tracking fixing fr-CA formats.

Current behavior was expected and otherHybridGlobalization tests are prepared for that. I am looking if we can provide a generic fix. For now this test can be blocked withPlatformDetection.IsNotHybridGlobalizationOnBrowser. The fix can get in in a separate PR

/azp run runtime-ioslike,runtime-ioslikesimulator,runtime-maccatalyst

/azp run runtime-ioslike,runtime-ioslikesimulator,runtime-maccatalyst

/azp run runtime

/azp run runtime