Date formatting behavior changes between Blazor Server and WebAssembly

Answer to the core questions

1. When does Blazor fall back to the invariant format?

• Blazor itself never substitutes the invariant format solely because CultureInfo changes. The ToString(format) call uses whatever culture is current on the executing thread.
• What can happen is that the format string contains culture‑sensitive specifiers (e.g., month names, AM/PM, era). If the new culture does not support those specifiers (because the runtime lacks full globalization data), the formatter may revert to a fallback pattern that looks like the invariant format.
• In WebAssembly, if the build does not enable full ICU data (via BlazorWebAssemblyLoadAllGlobalizationData), only the invariant culture is available. A custom format that relies on locale‑specific names will then be rendered using the invariant pattern.

2. Is formatting consistent across Server and WebAssembly without extra JS interop?

• Not automatically. Blazor Server uses the server’s Thread.CurrentCulture (often derived from the incoming request or a RequestLocalization middleware). WebAssembly defaults to the browser’s locale, and without full globalization data it may fall back to invariant.
• Even when both sides use the same culture name, the underlying ICU data can differ between the server OS and the WebAssembly runtime, leading to subtle differences in month names or date patterns.
• Therefore, consistency requires explicit culture synchronization, not just a shared format string.

3. How to preserve a user‑selected culture across navigation and reloads?

• Persist the culture name in a durable client‑side store such as localStorage or a cookie. Include it in the URL query string if you want to avoid storage.
• On app startup (in Program.cs for WASM or Startup.cs for Server), read the persisted value and set CultureInfo.CurrentCulture and CultureInfo.CurrentUICulture before the first component renders.
• For Server, avoid setting a global static culture that would affect all circuits. Instead, apply the culture per circuit by hooking into CircuitHandler or by configuring RequestLocalization to read the cookie on each request.
• In WebAssembly, ensure that the build includes full globalization data (add BlazorWebAssemblyLoadAllGlobalizationData=true to the project file) so that the persisted culture can be fully respected.
• After navigation, Blazor’s routing does not reset CultureInfo, so the persisted culture remains active. A full page reload will re‑apply the culture during startup, preserving consistency.

Diagnostic detail needed

To fine‑tune the recommendation, could you confirm which .NET runtime version you are targeting for WebAssembly and whether BlazorWebAssemblyLoadAllGlobalizationData is enabled? This determines if the client can use non‑invariant cultures.