Culture `en-CH` is different in WASM from server values

[alexaka1]

Description

If I use en-CH in my Blazor Web App, dates are formatted differently on the server and in the client.

I noticed that the CultureInfo.DateTimeFormat is substantially different in WASM from the server.

The following diff takes the server as base, and indicates wasm deviations:

{
- "AMDesignator": "AM",
+ "AMDesignator": "am",
  "Calendar": {
    "MinSupportedDateTime": "0001-01-01T00:00:00",
    "MaxSupportedDateTime": "9999-12-31T23:59:59.9999999",
    "AlgorithmType": 1,
    "IsReadOnly": true,
    "Eras": [
      1
    ],
    "TwoDigitYearMax": 2049
  },
- "DateSeparator": ".",
+ "DateSeparator": "/",
  "FirstDayOfWeek": 1,
  "CalendarWeekRule": 2,
  "FullDateTimePattern": "dddd, d MMMM yyyy HH:mm:ss",
  "LongDatePattern": "dddd, d MMMM yyyy",
  "LongTimePattern": "HH:mm:ss",
  "MonthDayPattern": "d MMMM",
-  "PMDesignator": "PM",
+  "PMDesignator": "pm",
  "RFC1123Pattern": "ddd, dd MMM yyyy HH\u0027:\u0027mm\u0027:\u0027ss \u0027GMT\u0027",
- "ShortDatePattern": "dd.MM.yyyy",
+ "ShortDatePattern": "dd/MM/yyyy",
  "ShortTimePattern": "HH:mm",
  "SortableDateTimePattern": "yyyy\u0027-\u0027MM\u0027-\u0027dd\u0027T\u0027HH\u0027:\u0027mm\u0027:\u0027ss",
  "TimeSeparator": ":",
  "UniversalSortableDateTimePattern": "yyyy\u0027-\u0027MM\u0027-\u0027dd HH\u0027:\u0027mm\u0027:\u0027ss\u0027Z\u0027",
  "YearMonthPattern": "MMMM yyyy",
  "AbbreviatedDayNames": [
    "Sun",
    "Mon",
    "Tue",
    "Wed",
    "Thu",
    "Fri",
    "Sat"
  ],
  "ShortestDayNames": [
    "Su",
    "Mo",
    "Tu",
    "We",
    "Th",
    "Fr",
    "Sa"
  ],
  "DayNames": [
    "Sunday",
    "Monday",
    "Tuesday",
    "Wednesday",
    "Thursday",
    "Friday",
    "Saturday"
  ],
  "AbbreviatedMonthNames": [
    "Jan",
    "Feb",
    "Mar",
    "Apr",
    "May",
    "Jun",
    "Jul",
    "Aug",
    "Sep",
    "Oct",
    "Nov",
    "Dec",
    ""
  ],
  "MonthNames": [
    "January",
    "February",
    "March",
    "April",
    "May",
    "June",
    "July",
    "August",
    "September",
    "October",
    "November",
    "December",
    ""
  ],
  "IsReadOnly": true,
- "NativeCalendarName": "Gregorian Calendar",
+ "NativeCalendarName": "gregorian",
  "AbbreviatedMonthGenitiveNames": [
    "Jan",
    "Feb",
    "Mar",
    "Apr",
    "May",
    "Jun",
    "Jul",
    "Aug",
    "Sep",
    "Oct",
    "Nov",
    "Dec",
    ""
  ],
  "MonthGenitiveNames": [
    "January",
    "February",
    "March",
    "April",
    "May",
    "June",
    "July",
    "August",
    "September",
    "October",
    "November",
    "December",
    ""
  ]
}

Am I missing something here? I was very surprised that they are different, I would not expect that at all.

Reproduction Steps

Follow this guide to enable globalization in wasm: https://learn.microsoft.com/en-us/aspnet/core/blazor/globalization-localization?view=aspnetcore-9.0#dynamically-set-the-culture-in-a-blazor-web-app-by-user-preference

Create 2 components, one with interactive server and the other with interactive webassembly with roughly the following:

@{
    var culture = CultureInfo.GetCultureInfo("en-CH");
}
<span>@DateTime.Now.ToString("G", culture)</span>

Expected behavior

Date is formatted as the following 18.10.2025 13:30:00 in all render modes.

Actual behavior

Date is formatted as 18.10.2025 13:30:00 on the server (static, interactiveserver).
Date is formatted as 18/10/2025 13:30:00 on the client (interactivewebassembly).

Regression?

No response

Known Workarounds

Patch the culture before setting the app's culture. I.e:

if (culture.IetfLanguageTag is "en-CH")
{
    culture = new CultureInfo(culture.IetfLanguageTag)
   {
       DateTimeFormat =
       {
           DateSeparator = ".",
           ShortDatePattern = "dd.MM.yyyy",
       },
   };
}

Configuration

.NET 9 SDK 9.0.306

Other information

No response

[dotnet-policy-service]

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

[dotnet-policy-service]

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

[pavelsavara]

cc @ilonatommy

[ilonatommy]

EFIGS contains en-CH, so it looks like it's the problem with ICU data contents https://github.com/dotnet/icu/blob/b1a86bc1c13b7a76ae353bdcb644f3718b04b158/icu-filters/icudt_EFIGS.json#L24

The file for "en-CH" specifies dependency on "en-150" and there are no date/time overrides, it only customizes number formatting:
https://github.com/dotnet/icu/blob/b1a86bc1c13b7a76ae353bdcb644f3718b04b158/icu/icu4c/source/data/locales/en_CH.txt
that contains the "generic" english date formatting:
https://github.com/dotnet/icu/blob/b1a86bc1c13b7a76ae353bdcb644f3718b04b158/icu/icu4c/source/data/locales/en_150.txt.

The upstream we're forking from is on a higher ICU version, 72. The corresponding file
https://github.com/microsoft/icu/blob/5f127ca12126f4be9fffab8176cc6d53c337b476/icu/icu4c/source/data/locales/en_CH.txt#L189
does contain the Swiss formatting for dates.

The fix would be to upgrade the ICU version. The last attempt was reverted here: dotnet/icu#353.

@lewing, is there any tracking issue for another attempt?

[ilonatommy]

if a fast fix is needed, the custom ICU build can be used docs.
Developers can copy the contents of the upstream file in microsoft/icu to dotnet/icu and build the ICU with the corrected data. It can serve as a workaround until we upgrade.

[Clockwork-Muse]

.... As an aside, I'll note that since the Blazor and server data sources are different, this condition can and will reappear without warning at some future date, completely outside of our control (the server ICU being a resource that comes from the host OS, not something we provide).

Even if we did control both, a web client is inherently a distributed application, and it's reasonable to expect that a client may be using a cached old version/file when it makes a call to a backend server.

To that end, as usual the standard recommendation to transfer things in a culture-neutral format such as ISO for interchange purposes will also handle this case.