The default date format used by QDate has a weird format (Fri Mar 7 11:34:02 2020), so I have changed this to a format that is more user-friendly (2020-03-07 11:34:02).
<img width="821" alt="Bitcoin Core New Date" src="https://user-images.githubusercontent.com/9567098/76152382-f8a37e00-60b6-11ea-8569-be6d69b892c6.png">
Concept NACK.
What is weird about the default date format? I find it clearer and more user friendly than the format you propose. It is clear and unambiguous about the day and month. The issue with strictly numeric date formats such as the one you propose is that different countries have standardized on different day and month order, so sometimes there is confusion as to which number is the date and month. By putting the month as the abbreviated month string, this is unambiguous.
I agree with what you're saying regarding the wording, I can change that back. The main reason for the change is the year being on the opposite end of the string. It was very hidden in my opinion.
Where does the default date string come from anyway? I wish there was a user setting. (I for one strongly agree with this change, but that's also because it's the format I would use myself.)
As a sidenote, @achow101 I don't think there is any ambiguity about 2020-02-03 being February 3rd, though. It's when you do 2/3 that some people think February, and others think March. (I think March 2nd) I could be wrong though...
Concept NACK.
ISO 8601 is good for international and machine readable stuff. However most people prefer to have the date format based on their locale
@emilengler This is obviously not the locale of the user though, or they would presumably not be confused enough to go through the trouble of making a pull request...
@dannmat Welcome!
Concept ACK on making ISO 8601 date format available to a user via settings. @kallewoof
I wish there was a user setting. (I for one strongly agree with this change, but that's also because it's the format I would use myself.)
Me too ;) @dannmat
... a weird format (Fri Mar 7 11:34:02 2020)...
... weird wording about local date format ;)
@kallewoof At least it has something to do with the system settings I think. On some systems and desktop this effects how date and times look. For example: iOS. I think Qt fetches this by default
@emilengler I think @kallewoof is saying that indeed the string should be localized according to the user's locale settings, but probably isn't done so correctly. If it was, the author likely wouldn't have decided to change it.
So after reading the documentation for QDate, I have found that QDate.toString() uses the QLocale class to retrieve a localized DateTime string.
The same information is provided in textual format by toString(). The day and month numbers can be mapped to names using QLocale.
I believe in this case, using a custom format (changed to include wording, e.g '2 July 2020 15:17:54') would be best, as it's more readable for the user and still uses localisation (string in French would still be '2 Juillet 2020 15:17:54').
Documentation for anyone who wants to take a look
Agree with NACK. User-presented dates are exactly the one place where locale-specfic formatting is desired.
FWIW on some OSes you can override the date/time locale if you don't like this (LC_TIME on Linux). As added bonus this will affect other software as well.
Ok, I think the consensus here is that we should stick with the original solution.