Trouble with AbbreviatedMonthNames

Question

It seems that the masses have spoken and basically the shorthand for September is now Sept.

So whilst Intl.DateTimeFormat Works on the principle (which my datepicker uses) my operating system has not got the memo (at present) and continues to work with Sep.

Anyway, so in an attempt to resolve this I've added in

CultureInfo ci = new CultureInfo("en-GB");

DateTimeFormatInfo dtfi = ci.DateTimeFormat;
dtfi.AbbreviatedMonthNames  = new  string[] {
                "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sept", "Oct", "Nov", "Dec", ""
            };
dtfi.AbbreviatedMonthGenitiveNames = dtfi.AbbreviatedMonthNames;

CultureInfo.DefaultThreadCurrentCulture = ci;
CultureInfo.DefaultThreadCurrentUICulture = ci;

Into my program file and this does seem to have resolve the issue and - I'm hoping that when Windows 11 comes around (for me) I might not need that code.

The question I have is - is this the right solution? My application is only going to be used in the Uk, but I'm a little wary. I seem to have created a new culture and basically forced the program to use it.

Is this the right approach?

--

Edit, sorry I'll backup slightly - so when it comes to datepickers I like to use the format dd-MMM-yyyy. It's pretty standard where users/staff can come from all parts and just removes any "ambiguity" over date formats. Uk vs US for instance.

---

As for official "The masses have spoken" - TBH I might have spoken out of turn. However https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat https://github.com/unicode-org/cldr/blob/b0a6207ff224a6cd8ca7f888c8a4740bacb83124/common/main/en_GB.xml#L1977 https://github.com/dotnet/runtime/issues/87307

There seems to be a few discussions about it .. And someone, somewhere did make the call...

--

Just for further clarity I'm using the Tempus Dominus datepicker. https://getdatepicker.com/ Which is using the Intl.DateTimeFormat methods.

Answer 1

So I think some of this depends on your operating system and choice of datapicker. For me using https://getdatepicker.com/ and on windows 10. The right way to fix this is

1. Install the Microsoft.ICU.ICU4C.Runtime via nuget
2. Create the file runtimeconfig.template.json in the root of the project

add in the content

{
      "configProperties": {
        "System.Globalization.AppLocalIcu": "72"
      }
    }

When you compile this it then goes into the runtimeconfig.json in the bin file. But that file can get overwritten (and probably is't source controlled if you are using such things.

And your done. On the whole this is probably the best method espicially if you are using that datepicker and developing an application that could be used in various conntries. (and also using the short month format ; - "MMM")

Answer 2

I can't tell whether this is the right solution, it depends on the purpose for which you must use Sept. Now .net uses the ICU library to achieve globalization. ICU changed the abbreviation for September from Sep to Sept in version 68 (CLDR-38). The latest version on Windows 11 should be 68 (you can find icu.dll in the system32 folder), So if you try updating the system, you should be able to see the Sept.

If you want to use a specific ICU version, you can compile or download the ICU dlls, put them in the root directory of the program, and then add the following lines to the .runtimeconfig.json file:

{
  "runtimeOptions": {
    "configProperties": {
      "System.Globalization.AppLocalIcu": "72"
    }
  }
}

This change will affect the behavior of Parse and ParseExact, with the majority of English cultures being affected, but en and en-US cultures still insist on using Sep.