Dates do not honour regional settings

[ChrisMaunder]

Type: Bug

When listing Git history, the dates against each commit are in the US-only month/day/year rather than the day/month/year or year-month-day format I have set on my machines. This makes it painful to scan the list looking for a specific date.

Extension version: 0.6.20
VS Code version: Code 1.82.2 (abd2f3db4bdb28f9e95536dfa84d8479f1eb312d, 2023-09-14T05:51:20.981Z)
OS version: Linux x64 6.2.0-33-generic snap
Modes:

[oldbasilbear]

I would certainly value this correction.

[andyhasit]

I gave someone completely wrong information last week, which I only realised today when I saw a US date format.

Software should either:

1. default to ISO (YYYY/MM/DD)
2. default to the format used by >98% of countries (DD/MM/YYYY)
3. make it follow localised settings
4. make it configurable.

But never, ever force US date format.

[halfrafu]

So I've gotten into a rabbit hole trying to fix this thing and came up with a hacky workaround to get my preferred format in history view which involves editing a minimized js file (barely readable) and adding a preferred locale as the first argument to two toLocaleString calls. Unfortunately JS API only allows to set the locale in which the date will be formatted. I'd suggest using en-SE which uses iso date and normal 24h clock.
Remember this "fix" will get removed when the extension gets updated.

So in short:

1. Go to ~/.vscode/extensions/donjayamanne.githistory-0.6.20/dist/browser/
2. Backup bundle.js because it's easy to screw up
3. Open bundle.js in notepad (can be done in vscode but lags a lot)
4. Find toLocaleString(, you should be at something like this: t.toLocaleString(e)}catch(e){return t.toLocaleString(void 0,n)}
5. Put "en-SE" (or your preferred locale) as the first argument, so replace e and void 0. You should end up with something like this: t.toLocaleString("en-SE")}catch(e){return t.toLocaleString("en-SE",n)}
6. Start (or restart) vscode and check the git history panel. If it opens, congratulations! If it doesn't you've screwed up.

And this is how it looks like:

I think the best way of fixing this would be to add a date locale option which would get passed to toLocaleString and try to get system locale setting if it's not set. Also there are some places where this extension uses toISOString which yields hard to read dates (still better than mm/dd/yyyy). These places should also use toLocaleString(whateverLocaleUsesHasChosen).