DateTimeFormatInfo.GetShortestDayName(DayOfWeek) is supposed to return names like Su, Mo, etc. as shown in the output of the example on the Microsoft documentation.
Instead, I get only one letter: S, M, etc.
Code to reproduce: (I'm using WPF .Net 6)
DateTimeFormatInfo en_us = CultureInfo.GetCultureInfo("en-US").DateTimeFormat;
string s = en_us.GetShortestDayName(DayOfWeek.Tuesday);
This is not useful to me since Tuesday and Thursday for example, have the same identifier. What could cause this issue, so that I can fix it and get the expected Su, Mo, etc. ?
You could add the following setting to your (.csproj) project file to not use the ICU globalization APIs that were introduced in .NET 5:
<ItemGroup>
<RuntimeHostConfigurationOption Include="System.Globalization.UseNls" Value="true" />
</ItemGroup>
This is likely "by design" as outcome of switching from Windows-specific way of getting globalization information to publicly available data.
Following article Breaking change: Globalization APIs use ICU libraries on Windows explain the change (but indeed does not go into specifics like "if short names are changed"):
Starting in .NET 5, if an app is running on Windows 10 May 2019 Update or later, .NET libraries use ICU globalization APIs, by default.
And the ICU site lists abbreviations as one of the components (highlighting is mine):
Formatting: Format numbers, dates, times and currency amounts according the conventions of a chosen locale. This includes translating month and day names into the selected language, choosing appropriate abbreviations, ordering fields correctly, etc. This data also comes from the Common Locale Data Repository.
This appears to be a change from .NET 4.7.2 to .NET Core 6 (possibly all versions of .NET Core - I can't confirm right now).
In .NET 4.7.2 I get two-character results; in .NET 6 I get one-character results.
I also don't see any documentation online that indicates that the change was an intentional breaking change.
I would submit a bug ticket to either update the documentation (and admit that it was a breaking change) or revert the behavior.
A workaround would be to take the first two characters of GetAbbreviatedDayName.