Enable Globalization to read the user setting overrides for current cultures when using ICU

[DmitryGaravsky]

Description

The DateTimeFormatInfo properties in Net Core 5 Preview 4 return different culture-specific information about the format of date and time values compared to .Net Framework in the same environment

Our unit tests detected this issue immediately. (we maintain unit tests for all the released and preview environments like .net core 5 in our codebase). Thus it is an important breaking change for us.

Configuration

OS Version: Microsoft Windows [Version 10.0.18362.535]
.Net Framework Version: Microsoft (R) .NET CLR Version Tool Version 4.8.3928.0
.Net Core Version: SDK Version: 5.0.100-preview.4.20258.7

Regression?

Yes, this works correctly until .Net Core 5 Preview 4

Other information

Here are some tests which fail under .Net Core 5 Preview 4

[TestCase("en-US", "M/d/yyyy", "dddd, MMMM d, yyyy")]
[TestCase("ru-RU", "dd.MM.yyyy", "d MMMM yyyy 'г.'")]
public void DatePatterns(string culture, string pShort, string pLong) {
	CultureInfo c = new CultureInfo(culture);
	Assert.AreEqual(pShort, c.DateTimeFormat.ShortDatePattern);
	Assert.AreEqual(pLong, c.DateTimeFormat.LongDatePattern);
}
[TestCase("en-US", "h:mm tt", "h:mm:ss tt")]
[TestCase("ru-RU", "H:mm", "H:mm:ss")]
public void TimePatterns(string culture, string pShort, string pLong) {
	CultureInfo c = new CultureInfo(culture);
	Assert.AreEqual(pShort, c.DateTimeFormat.ShortTimePattern);
	Assert.AreEqual(pLong, c.DateTimeFormat.LongTimePattern);
}
[TestCase("en-US", "January", "Jan")]
[TestCase("ru-RU", "Январь", "янв")]
public void MonthNames(string culture, string name, string abrName) {
	CultureInfo c = new CultureInfo(culture);
	Assert.AreEqual(name, c.DateTimeFormat.MonthNames[0]);
	Assert.AreEqual(abrName, c.DateTimeFormat.AbbreviatedMonthNames[0]);
}
[TestCase("en-US", "January", "Jan")]
[TestCase("ru-RU", "января", "янв")]
public void MonthGenitiveNames(string culture, string name, string abrName) {
	CultureInfo c = new CultureInfo(culture);
	Assert.AreEqual(name, c.DateTimeFormat.MonthGenitiveNames[0]);
	Assert.AreEqual(abrName, c.DateTimeFormat.AbbreviatedMonthGenitiveNames[0]);
}

[stephentoub]

I expect this is by-design and due to switching to using ICU instead of NLS by default for globalization.
https://github.com/safern/runtime/blob/c592559b25de2bcc2ddf8adcb94a9a37fe1d10ce/docs/design/features/globalization-icu.md
cc: @safern, @tarekgh

[tarekgh]

@stephentoub is right. We are now using ICU by default. the doc link that @stephentoub mentioned has the way how to switch back using NLS instead of ICU to revert back to the old behavior. Please send any questions you have and we'll be happy to help with.

[DmitryGaravsky]

Thanks, @stephentoub and @tarekgh

I clearly understand the reason - using ICU instead of NLS.
The single point I can't understand is "Why the results have taken via ICU does not match OS settings for current culture?".

Should I always switch back to NLS to create desktop applications that take OS settings into account?

[safern]

@Dmitri-Botcharnikov maybe you're hitting this issue: #35638 ?

This was fixed for Preview5. Could you try with our latest release and see if that works as expected?

You can get the latest daily build from here: https://github.com/dotnet/installer/blob/master/README.md#installers-and-binaries

[tarekgh]

@DmitryGaravsky that is a good point. we may try to look at this one and figure out if it make-sense using the overrides from the System. I am not expecting users to switch back to NLS just to pick the overrides.

[ghost]

Tagging subscribers to this area: @tarekgh, @safern, @krwq
Notify danmosemsft if you want to be subscribed.

[tarekgh]

@DmitryGaravsky I have changed the title of the issue just to reflect what needs to be fixed.

[safern]

Thanks @tarekgh I've self assigned to start looking into it.

[DmitryGaravsky]

Thanks, guys! I'll stay tuned

[iSazonov]

What .Net preview version is we get the fix in?

[safern]

This is going to land on Preview8. I can’t point you to the first daily build that contains the fix for Powershell to try it out.

[safern]

@iSazonov I forgot to let you know as we were having trouble to update the SDK to a new runtime, but the latest daily SDK should contain this fix if you want to try it 😄

https://aka.ms/dotnet/net5/dev/Sdk/dotnet-sdk-win-x64.exe

https://github.com/dotnet/installer/blob/master/README.md#installers-and-binaries