The date/time format of the LC_TIME located is not regarded. STEPS TO REPRODUCE: 1. Ensure the DK locale is enabled (add/uncomment it in cat /etc/locale.gen): # cat /etc/locale.gen | grep -v "^#" en_DK.UTF-8 UTF-8 en_US.UTF-8 UTF-8 2. In /etc/locale.conf change LC_TIME to become en_DK.UTF-8 (ISO date): # sed -i 's/^LC_TIME=[a-zA-Z0-9\_\.\@-]*/LC_TIME=en_DK.UTF-8/' /etc/locale.conf 3. Generate new locales: # locale-gen Generating locales... en_DK.UTF-8... done en_US.UTF-8... done Generation complete. 4. Launch Krusader and see the date/time format in the columns OBSERVED RESULT: You will see no change of date/time format form en_US locale to en_DK locale (ISO) EXPECTED RESULT: You want to see that the date/time format has changed from en_US locale to en_DK locale (= ISO format) SOFTWARE/OS VERSIONS: Linux: ArchLinux 18.08 (Linux 4.17 --- upgraded to ---> Linux 4.18.5) Krusader: ArchLinux package krusader 2.7.1-1
Pls forgive me the typo. The summary should be... The date/time format of the LC_TIME locale is not regarded.
Assuming that Krusader uses Qt to format date/time strings: The Qt library uses the CLDR data to map locale identifiers to format strings. As far as I know, the en_DK locale is not in the CLDR database. https://unix.stackexchange.com/questions/62316/why-is-there-no-euro-english-locale has more information, including: 'The name "en_DK" is sort of a joke...'
Related: bug 340982 and (invalid) https://bugreports.qt.io/browse/QTBUG-35692
So do I get this right... In case I use the time locale "en_US.UTF-8" (to avoid en_DK.UTF-8), and then manually edit /usr/share/i18n/locales/en_US to make the date/time representation of "%x %X" becoming ISO, then Krusader still don't care for the system settings, but simply does its own ***HARDCODED*** thing, while all the rest of the system regards my system-wide LC_TIME settings??? STEPS TO REPRODUCE: # vi /usr/share/i18n/locales/en_US ... % Appropriate date representation (%x) %d_fmt "%m//%d//%Y" d_fmt "%Y-%m-%d" % % Appropriate time representation (%X) %t_fmt "%r" t_fmt "%H:%M:%S" ... # vi /etc/environment ... LC_TIME="en_US.UTF-8" ... # locale-gen # date +"%x %X" 2018-11-14 09:25:20 OBSERVED RESULT: Krusader does not regard LC_TIME EXPECTED RESULT: All applications should regard the LC_TIME settings
Yes. The CLDR database has more information than provided by the POSIX interfaces, so Qt developers decided to implement QLocale using an internal copy of the CLDR data.
It is possible to overwrite classes like QTableWidget and handle the format of the 'modified date' column according to kdeglobals, as it was before in Krusader (2.4.0 beta1)... $ vi ~/.kde/share/config/kdeglobals ... [Locale] DateFormatShort=%Y-%m-%d TimeFormat=%H:%M:%S This was very handy and platform-independent as well? Easy and handy sorting by the 'modified date' column is essential for file managers. Krusader is such a handy software - so those little, but very much helpful things would be a brilliant enhancement.
The ~/.kde/share/config/kdeglobals was not platform-independent. It was supported by custom logic in KDE4 libs (KLocale class), AFAIR. https://community.kde.org/KDE_Core/KLocale#Qt5_.2F_KDE5 > Using KLocale (and thus KConfig) is a major barrier to Qt-only apps adopting our libraries so we should try remove the need for KLocale where-ever possible. Much can be achieved by pushing KLocale features into QLocale and ensuring QLocale fully supports all options common to all the platforms (some options are still not supported, or are only properly supported on some platforms). So we migrated to QLocale during KF5 migration. I agree that system setting should be respected in Qt (in case not explicitly overridden). Please open a bug in Qt bug tracker and reference it here.