Same as D5345
Same as the other diff, if safe, good to go.
EDIT: I feel like we could wrap the Qt.locale(Qt.locale().uiLanguages) into something shorter, maybe.
Possibly also keep it instantiated around.
The thing this fixes is there.
It's arguably a tiny bit less relevant as people might now use a custom date format in just the digital clock, instead of choosing a different locale for times.
FWIW, I submitted a change that did exactly this at the "correct" layer in Qt: https://codereview.qt-project.org/c/qt/qtbase/+/139295
This is doing the same thing but with a parsing layer before we do the parsing....which is both really clever and horrificly mad at the same time.
The solution won't work in all cases. For example:
QLocale(QLocale::Portuguese).dateFormat() = "dddd, d 'de' MMMM 'de' yyyy"
So with this, if I have English language with portuguese time locale I still get "Thursday, 29 de October de 2015". which is still wrong.
Marking as request changes to get it out my queue, as I think it needs more discussion after my comment above
I could be maybe persuaded, but adding a bad hack that only works for some situations doesn't seem like a good idea.