KDE and ISO date revisited. Anybody that knows where to find the definitions?

[hcvv]

KDE 5 is not able to customize the short date representation to ISO. This was already so since it started (it was simple configurable in KDE 4 and earlier), but feeling urged to move to it from KDE 4 I revisited this show-stopping issue.

The KDE bug is here: https://bugs.kde.org/show_bug.cgi?id=340982

According to other sources on the internet, choosing Denmark-English (en_DK) should help in at least showing a correct ISO formatted short date (though not my local Dutch names for monthes and days). I tried it, but it gave 02/06/2018. Well at least it shows clearly what the year is and thus the rest can be concluded. I decided to live with this for the time being.

But reading the last post of the KDE bug:

not a solution at all, but an ugly workaround.

on fedora 27 (plasma 5.10.5):

add “LC_TIME=en_DK.UTF-8” to /etc/locale.conf
in kde, set “System Settings” -> “Regional Settings” -> “Formats” -> “Time” to “Sweden - English (en_SE)”

for some reason, the en_DK definition in qt/kde5 has the wrong date order, but en_SE (which i’ve never heard of and doesn’t exist in the system locale database) has the correct one.

this will give you:

english long date
iso short date (YYYY-MM-DD)
24-hour clock

I tried Sweden-English (en_SE) and indeed I got 2018-06-02 for today!

BUT.
Now that it is proven that KDE CAN create the correct date specification, I wonder where that is defined in KDE. Somewhere there must be a table that defines what to do with which LC_TIME definition. And IMHO there is an error there for en_DK, but when one can compare what is there for en_SE a correction might be possible. Not that I want to correct for en_DK, but I want of course correct nl_NL (which is utterly wrong.

Or is it not a configuration table somewhere, but is it hard-coded in some library?

[Fraser_Bell]

AFAIK it is an issue upstream at QT.

I believe changes would need to be made to QT instead of in KDE/Plasma, because KDE/Plasma would need major changes. Problem comes from KDE deciding to drop their implementations and just use the QT stuff.

… as best as I can decipher it all.

People complain, QT just ignores, KDE half ignores (because of the work, I believe) or other half says complain to QT, and around and around in a merry-go-round.

[hcvv]

@Fraser_Bell

AFAIK it is an issue upstream at QT.

I believe changes would need to be made to QT instead of in KDE/Plasma, because KDE/Plasma would need major changes. Problem comes from KDE deciding to drop their implementations and just use the QT stuff.

… as best as I can decipher it all.

People complain, QT just ignores, KDE half ignores (because of the work, I believe) or other half says complain to QT, and around and around in a merry-go-round.

I have all read that already. But I am not interested in who blames who upstream. Fact is that as long as they are blaming, the user does not have a solution.

What I ask for is, taking into account that en_SE produces a correct ISO short date and that thus the software (whoever thinks being responsible for it or not) can do it, but that it doesn’t do it in en_DK (which is apperantly another one where it should work), there must be some definition what to do with what value of LC_TIME somewhere in the system.

My question is: where is that definition? In the hope that I can understand it and change it.
I admit that the answer can onlu be given by someone who knows more about the internals of KDE or any of the other letter combinations involved, but I hope that there is such a person here on the forums.

The alternative is a sort of brute force approach by e.g. searching for character strings like LC_TIME and en_SE through all files on the system. But I hope that time can be saved.

[Fraser_Bell]

@hcvv

I have all read that already. But I am not interested in who blames who upstream. Fact is that as long as they are blaming, the user does not have a solution.

What I ask for is, taking into account that en_SE produces a correct ISO short date and that thus the software (whoever thinks being responsible for it or not) can do it, but that it doesn’t do it in en_DK (which is apperantly another one where it should work), there must be some definition what to do with what value of LC_TIME somewhere in the system.

My question is: where is that definition? In the hope that I can understand it and change it.

Okay, was just checking, because I have been looking for an answer for a long time, as well.

I quit KDE at the change to Plasma5 for that reason and for other intentional forced regressions. Will not even consider going back until they finally start to respond to their Users in a more positive manner. But, that would require them to first start responding.

I admit that the answer can only be given by someone who knows more about the internals of KDE or any of the other letter combinations involved, but I hope that there is such a person here on the forums.

I have been hoping, as well, for such enlightenment.

The alternative is a sort of brute force approach by e.g. searching for character strings like LC_TIME and en_SE through all files on the system. But I hope that time can be saved.

I would not want to have to do that.