Incorrect DateTimeFormat for nb-NO in Blazor WebAssembly

[AbstractionsAs]

Description

Getting month and day names returns incorrect values.
Months come back as M01, M02, etc
Days come back as English day names

Reproduction Steps

var culture = CultureInfo.GetCulture("nb-NO");

// Should return 'mars', returns 'M03'
var march= culture.DateTimeFormat.GetMonthName(3);

// Should return 'tirsdag', returns 'Tuesday'
var tuesday = culture.DateTimeFormat.DayNames[2];

Expected behavior

Should return the correct values

Actual behavior

Returns incorrect values

Regression?

No response

Known Workarounds

No response

Configuration

.net 6
Windows 10 (WebAssembly)
x64
Spesific to blazor WebAssembly
All browsers

Other information

No response

[ghost]

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

Issue Details

---

Description

Getting month and day names returns incorrect values.
Months come back as M01, M02, etc
Days come back as English day names

Reproduction Steps

var culture = CultureInfo.GetCulture("nb-NO");

// Should return 'mars', returns 'M03'
var march= culture.DateTimeFormat.GetMonthName(3);

// Should return 'tirsdag', returns 'Tuesday'
var tuesday = culture.DateTimeFormat.DayNames[2];

Expected behavior

Should return the correct values

Actual behavior

Returns incorrect values

Regression?

No response

Known Workarounds

No response

Configuration

.net 6
Windows 10 (WebAssembly)
x64
Spesific to blazor WebAssembly
All browsers

Other information

No response

Author:	AbstractionsAs
Assignees:	-
Labels:	area-System.Globalization, untriaged
Milestone:	-

[ghost]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

Getting month and day names returns incorrect values.
Months come back as M01, M02, etc
Days come back as English day names

Reproduction Steps

var culture = CultureInfo.GetCulture("nb-NO");

// Should return 'mars', returns 'M03'
var march= culture.DateTimeFormat.GetMonthName(3);

// Should return 'tirsdag', returns 'Tuesday'
var tuesday = culture.DateTimeFormat.DayNames[2];

Expected behavior

Should return the correct values

Actual behavior

Returns incorrect values

Regression?

No response

Known Workarounds

No response

Configuration

.net 6
Windows 10 (WebAssembly)
x64
Spesific to blazor WebAssembly
All browsers

Other information

No response

Author:	AbstractionsAs
Assignees:	-
Labels:	arch-wasm, area-System.Globalization, untriaged
Milestone:	-

[tarekgh]

CC @lewing

[lewing]

This is likely a result of the way we strip down the formatting data for size reasons. Can you explain your use case to help us prioritize changes?

[AbstractionsAs]

In my case I became aware of the problem because I was using the 'BlazorDateRangePicker' in an application, and it was giving me a calendar with wrong information in it. When setting the culture manually didn't work, I started investigating. The use case is a date picker. If this isn't solved I will either have to fall back to a JavaScript implementation, or fork the component and hard code all values for the most important cultures myself. Our market is Norway, and thus the user interface needs to properly support Norwegian. Skaff deg Outlook for Android<https://aka.ms/ghei36>

…

________________________________ From: Larry Ewing ***@***.***> Sent: Wednesday, March 30, 2022 3:56:08 AM To: dotnet/runtime ***@***.***> Cc: Christian Ruud ***@***.***>; Author ***@***.***> Subject: Re: [dotnet/runtime] Incorrect DateTimeFormat for nb-NO in Blazor WebAssembly (Issue #67115) This is likely a result of the way we strip down the formatting data for size reasons. Can you explain your use case to help us prioritize changes? — Reply to this email directly, view it on GitHub<#67115 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AXR4SXM6X2YMNKTBRSMXVODVCOYDRANCNFSM5RSGF45Q>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[ilonatommy]

Thank you for reporting it, we are aware of the problem. This is a duplicate of #53239.