HebrewCalendar not working properly on client side blazor

[ysroels]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

printing DateTime using "he-IL" CultureInfo and the HebrewCalendar outputs the date with the month written in digits or using Latin characters instead of Hebrew characters.

Expected Behavior

The expected output of a DateTime printed using a "he-IL" CultureInfo that uses the HebrewCalendar would be fully in Hebrew characters (as is indeed the case when printing a DateTime on the server instead of client side)

Steps To Reproduce

string GetHebrewDate(DateTime d)
    {
        var hc = new HebrewCalendar();
        var culture = CultureInfo.CreateSpecificCulture("he-IL");
        culture.DateTimeFormat.Calendar = hc;
        return d.ToString("dd MMM yyyy", culture);
    } 

var d = new DateTime(2024,0,12);
var a = GetHebrewDate(d);

//EXPECTED:
//d = "ט' אלול תשפ"ד"

//ACTUAL:
//d = "ט' Elul תשפ"ד"

Exceptions (if any)

No response

.NET Version

confirmed on 7

Anything else?

No response

[javiercn]

@ysroels thanks for contacting us.

You might need to configure additional settings on your project. See https://learn.microsoft.com/en-us/aspnet/core/blazor/globalization-localization?view=aspnetcore-8.0#net-globalization-and-international-components-for-unicode-icu-support-blazor-webassembly

[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 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

[Clockwork-Muse]

Expected Behavior

The expected output of a DateTime printed using a "he-IL" CultureInfo that uses the HebrewCalendar would be fully in Hebrew characters (as is indeed the case when printing a DateTime on the server instead of client side)

Pedantically, this isn't actually guaranteed (although it is likely). Culture data is sourced from the OS, and is subject to change without warning for no obvious reason. You should not rely on its stability.

[ilonatommy]

@ysroels, what globalization settings are you using? Do you have

<PropertyGroup>
  <BlazorWebAssemblyLoadAllGlobalizationData>true</BlazorWebAssemblyLoadAllGlobalizationData>
</PropertyGroup>

set?

[ysroels]

@ilonatommy I do indeed have that set.
Hebrew month names (in Hebrew characters) are probably a part of International Components for Unicode (ICU) as @javiercn alluded, for which tooling is scheduled in November for .Net 9.

[ilonatommy]

It seems to be a blazor-only issue, on WASM app the problem does not exist. I will update when I have more info.

[ilonatommy]

There are two issues connected with this report. One is the know effect of trying to limit data loaded to browser - we're not adding all possible ICU data, even with BlazorWebAssemblyLoadAllGlobalizationData. You can look up the filters used for the "full" set here: https://github.com/dotnet/icu/blob/dotnet/main/icu-filters/icudt_wasm.json.
As you can notice, we are adding additionally a few calendars:

{
            "categories": ["locales_tree"],
            "files": {
                "blacklist": ["root"]
            },
            "rules": [
                "-/calendar/*",
                "+/calendar/default",
                "+/calendar/gregorian",
                "+/calendar/generic"
            ]
        },

but not +/calendar/hebrew. You can edit it for yourself and then build the ICU locally with ./build.sh /p:TargetOS=Browser /p:TargetArchitecture=wasm - the detailed docs can be found in docs.
I created 2 versions: one is the "full" ICU + hebrew calendars and the other is no_CJK no_cjk_filters + hebrew calendar, attaching them here for your reference.
You're loading them with

<BlazorIcuDataFileName>path/To/icudt_no_CJK_he_cal.dat</BlazorIcuDataFileName>

icudt_with_he_cal.zip

The other issue is that if you are using net9 of P7+, with fingerprinting, you can have problems with loading that custom file - we're fixing it in #108011 and will backport it asap. Without this fix you can load custom ICU only if you disable fingerprinting: <WasmFingerprintAssets>false</WasmFingerprintAssets>.

There's a minor mistake in the repro code: we cannot index months from 0, DateTime.

Let me know if this worked.

[ilonatommy]

Culture data is sourced from the OS, and is subject to change without warning for no obvious reason. You should not rely on its stability.

In WASM apps, culture data is sourced from icu transport nugets that change when there's a change in CLDR. Using the OS's NLS applies to applications that do not run in browser's sandboxed environment.

[Clockwork-Muse]

In WASM apps, culture data is sourced from icu transport nugets that change when there's a change in CLDR. Using the OS's NLS applies to applications that do not run in browser's sandboxed environment.

Sure, but at that point the nuget packages are essentially the OS packages (NLS or not), and the same considerations apply.

[dotnet-policy-service]

This issue has been marked needs-author-action and may be missing some important information.

[dotnet-policy-service]

This issue has been automatically marked no-recent-activity because it has not had any activity for 14 days. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will remove no-recent-activity.