1

Chrome, Firefox, and Edge all seem to use the OS's setting, not the client's "Accept-Language" setting, in determining what date format to use in the control. My problem is, the rest of my site uses the "Accept-Language" setting to determine the date format. So, if the user's settings disagree in the browser vs. OS, as seems to be common, I might a date string shown on the page with a MM/dd/yyyy format in one place and a dd-MM-yyyy in an input element on the same page

Now I don't mind going either way with this as long as it is consistent. How can I make it so browser's date input and Blazor's .ToString() use the same date format even when the browser and OS have different settings? I see here directions on how to use the Accept-Language header automatically (sent based on client's browser settings), but it seems that HTML input controls don't respect this and instead use the OS setting.

Can I change the input[type=date] control to use the Accept-Language setting for its format, rather than the OS setting?

Assuming I cannot, can it be done the other way around? How do I make the rest of my Blazor WebAssembly site use the culture of the OS as the current culture rather than as specified in "Accept-Language"?

Here's a screenshot of my site with the contradictory date formats. My OS (Windows 10) is set to "English India", and my Accept-Language in the browser is "en-US".

enter image description here

For the above example : here is my Windows setting and the browser client setting.

Windows setting Browser Accept-language setting

Patrick Szalapski
  • 8,738
  • 11
  • 67
  • 129
  • Your claim around `type="date"` is in direct contradiction with [this demo](https://learn.microsoft.com/en-us/aspnet/core/blazor/globalization-localization?view=aspnetcore-5.0&pivots=webassembly#demonstration-component-1). – H H Oct 13 '21 at 12:54
  • 1
    O, but that docs page seems to be wrong about using Invariant culture for type=. That makes it match my (custom) OS settings too. Aside from that your issue appears to be "as designed" . How would omitting `type=` work in your situation? – H H Oct 13 '21 at 13:24
  • Yes, that page also notes "When using the date and number field types, specifying a culture with @bind:culture isn't recommended because Blazor provides built-in support to render values in the current culture." – Patrick Szalapski Oct 13 '21 at 13:29
  • So "as designed" there is no way to have the same date format in inputs vs. strings unless OS and browser setttings match? In other words my site will be inconsistent and I have to tell users to fix their browser settings? They won't like that, hmm, I wonder what I can do... – Patrick Szalapski Oct 13 '21 at 13:34
  • You mean avoiding the date picker altogether? Then it wouldn't be a date at all. I think I'd have to move to a Blazor date picker component that doesn't use the formatting of the input[type=date] HTML element, which would be a shame because the built-in HTML date picker is everything I need otherwise. – Patrick Szalapski Oct 13 '21 at 13:34

1 Answers1

0

I could not find a way to do this with the native browser <input type="text"/>, as it appears to use OS control that uses the OS setting. I believe this to be a missing feature in most browsers.

The only fix I found was to switch to a third-party Blazor component such as RadzenDatePicker for all my date inputs.

Patrick Szalapski
  • 8,738
  • 11
  • 67
  • 129