Could not parse the date format

[salvis]

Running Fusion++ for the first time, I hit this:

Too bad you didn't get any follow-up on #34...

I logged a build action in Visual Studio, and besides MSBuild.exe, this also called PowerShell.exe. Strangely enough, the PowerShell logs have
*** Assembly Binder Log Entry (30.03.2023 @ 10:30:14) ***
while the MSBuild logs have
*** Assembly Binder Log Entry (23-03-30 @ 10:29:42) ***

My Windows 10 settings are Country=Switzerland, RegionalFormat=English (United Kingdom), and ShortDate="yy-MM-dd". It seems like PowerShell is ignoring all but the Country setting, and this is inherited by the Assembly Binder.

To make things even more interesting, my WindowsDisplayLanguage is English (United States), and my Keyboard is set to a customized version of English (United States), but I don't think this is part of the problem.

My CurrentCulture shows en-GB and my CurrentUICulture en-US. I don't know where .NET is hiding the Country=Switzerland setting that PowerShell seems to use.

(The reason for this unusual set-up is that I'm a native Swiss living and working in Switzerland, but I prefer to work with a US English UI and keyboard, except I need UK English for my printers to default to A4 rather than Letter, and I've customized the US keyboard to give me umlauts etc. using special key sequences.)

So, if I knew how to retrieve the Country=Switzerland setting (that's where "dd.MM.yyyy" comes from!), I would recommend to use that as an additional fallback, but there are 8 "CH" CultureInfos. They disagree on the SortDatePattern and it's unclear which one you'd have to take. The only other source of regional information that I find is System.Globalization.RegionInfo.CurrentRegion, but that one shows the UK region for me, which wouldn't work either.

As a last resort, there's the registry: HKCU\Control Panel\International\ has
— User Profile\Languages: en-US de-CH fr-CH
— User Profile System Backup\Languages: de-CH en-US
The standard CultureInfo("de-CH") would provide the correct ShortDatePattern as a fallback.

P.S. Other sessions that don't include PowerShell work fine for me — very nice work, thank you! It was just bad luck that I hit PowerShell on my first attempt to use Fusion++.

[awaescher]

Just came back to this issue and I have to tell ... I have no clue what do to with this 😅

[salvis]

Maybe allow the user to configure an alternative fallback date format? Or try the CultureInfos for the cultures in
HKCU\Control Panel\International\User Profile\Languages
per process, until one of them fits?

Or assume that all dates are for the same day, or even just for today, if you can't parse them. This is likely to cover 99% of the usages. I doubt that a lot of people let Fusion++ collect logs overnight.

I realize that this is a pain, but aborting is not a good solution...

Maybe this sheds some light on the issue:
https://stackoverflow.com/questions/62909619/powershell-uiculture-vs-windows-setting
Or at least it documents that PowerShell's behavior is, er, noteworthy...

It's strange that PowerShell seems to be able to influence the CultureInfo used for formatting the log entries. The script was called in a Visual Studio build step and I have no idea what it does. However, since you're already displaying the offending timestamp, the user could easily figure out the proper fallback format, which may not be the same for every run! Configuring one (or even a series of) date format(s) could allow to successfully treat those odd scenarios.

[awaescher]

You can't surely tell if the cultures under HKCU\Control Panel\International\User Profile\Languages would have done it in your case, do you?

[salvis]

Yes, they would have, but this may be a coincidence.

PowerShell's behavior is so confusing, and apparently even version-dependent.