I can confirm this.
YYYY-MM-DD is defined as the international standard in ISO 8601 and ought to be easy to find.
To set your locale to use ISO 8601, you have to set LC_TIME=en_DK. This does the trick for some applications, however, not for KDE (Plasma 5 and KDE applications). Neither can I find en_DK in Regional Settings under "Time".
Please make KDE respect the system locale.

There are other settings missing too. It is a MUST to be able to change the ISO date, metric system, customize decimal separator for convenience.
I'm Polish and I can't stand Polish translation so I use en_US, but I can't stand middle-endian date, so I set ISO date and 24H time. Then I want to use EUR as the currency. I miss KDE 4 settings.
KDE5 has to have advanced settings.

I agree that this is needed. My use case is that I want ISO 8601 date (yyyy-mm-dd) with 24-hour time in the panel clock, which I'm able to do in Plasma 4.

On the current KDE (4) in F21 one can go to "System Settings --> Common Appearance --> Locale --> Country/Region" and separately set the format of "Numbers", "Money", "Calendar", "Date&Time" and other things such as page size.

Now, with Plasma 5 there is a "Personalization --> Formats" section but I can't seem to find a way to set the Time Format to HH:MM:SS such that AM/PM isn't displayed and I get the time in the clock in 24hr format.  I could set it to UK, but being originally from the US I'm used to MM/DD/YY not DD/MM/YY as the UK has it.  So, my work around is to create .bashrc settings for LC_TIME.

There are other settings which are configurable in KDE 4, but no longer the option in KDE 5.  Loss of functionality is normally as step backwards.

Please note this is a missing feature and must be implemented ideally on Qt's side

This is a regression resulting from the switch from KDE's powerful locale and formatting classes to the inferior Qt-only ones, as part of the Frameworks initiative (that aimed at reducing interdependencies between KDE classes so that KDE can now ship a bazillion small "Frameworks" instead of a single coherent kdelibs framework). Sadly, loss of functionality was not considered a blocker for any of those K*→Q* ports.

Created attachment 91725 [details]
132 DPI KF5.8 locale's "Time" select list screenshot

This shows that there's really no way to find out from within systemsettings even *if* a desired format is available. The unwieldly populous select list is not alpha-sorted, has no preview of any selection, and has no apparent offer of the ISO 8601 format that isn't tied to any particular locale.

Just loaded up Kubuntu 15.04 and ran into this. This in my mind is a pretty big frustrating regression from user convenience point of view. Nobody wants to see their clocks or currency or decimals in a format other than what they expect. Some countries even have multiple standards due to regional/language differences... Canada's got its own Wikipedia page on it! http://en.wikipedia.org/wiki/Date_and_time_notation_in_Canada

More importantly, your preset drop down solution is - as Felix stated - poor. Nobody should have to scroll through that list in 2015 to get a desired format, it is way too long. 

Love KDE and appreciate the work of the devs, but this needs to be fixed and if that means bringing back KDE's complex classes I say make it so. Personally I'll just restore my dd backup image of 14.04, but expect a lot of annoyed users who took a distribution upgrades within the month and didn't image. I think it is poor form personally, but I'm not involved in your decision making.

Reinstating KLocale is really not an option, it's tied in everywhere, would break API and ABI in multiple places and is just too much effort to do. Really, the solution is to put features one by one into QLocale, and that won't happen overnight. Giving advise is nice, but won't change anything in itself. Anybody's help is of course welcome here. Yours, too.

That said, I think Jeremy that you may want to have another look into the Regional Settings | Formats settings page. For example, there are two entries for Canada (en_CA, fr_CA). This reflects these regional differences. Also, you can set the formats for currency and time (and others) separately.

The dropdown also has keyboard completion. I agree that it's not super user-friendly, but maybe you haven't noticed that yet and it helps.

This actually reflects the locale system that is used system-wide on Linux, so non-Qt/KDE apps are now able to pick up these settings as well.

How does one set en_DK in KDE now?
I really need ISO date. I need a week to start on Monday. I need metric system and still use English.
Looks like I am not the only one.
On a side note - there is no preview for short date too,

Setting separate language and region should be possible, as well as displaying a short date preview. I'll have a look into it.

@Sebastian, sorry if I came off the wrong way, especially as giving programming advice. I'm not knowledgeable enough on the code base to be that presumptuous. I'm just trying to express what I see as a KDE user. Others will likely be saying the same things as they upgrade desktop/notebooks. I don't think users will expect the Locale system to undergo such a large regression in configuration. It isn't a feature most people check in the changelog/notes.

I saw the separate drop downs and know about keyboard completion, and yes there is en_ca & fr_ca but that represents only two choices based on system locale for a field (say datetime or currency). If I don't like either of those choices, then as a user I have to iterate through the drop down hoping another country's preset is to my liking. That is tedious and unfriendly. By comparison, KDE4 offered this easily customized page https://userbase.kde.org/images.userbase/7/7a/Settings-locale.png . Each setting individually customized. 

I get as a programmer this regression arose because QT's Locale is inferior to KDE's. Users only care about what _IS_  though, not why it is. As for patching QLocale, that seems like the best solution but it is a bit late in the game to be doing that. It will take several releases I assume. KDE5 is shipping default now. 

I'm not trying to assign any blame or demand a fix or be hostile. I genuinely want KDE to be the best. I personally already reverted to my KDE4 Kubuntu 14.04 image over this regression & a few other quirks I spotted. Other less technical users though may be surprised/frustrated after dist upgrades, that's what I'm getting at. All they will see is KDE 5 Locale < KDE 4 Locale. 

Best wishes,

Jeremy

Just curious, how do GNOME or other desktop users configure their locales? Since Plasma 5 now uses the system locale, instead of doing its own thing, aren't there any other (non-KDE4) Linux users, that need to customize the formats?

@Christoph Feck, As far as adjusting the time format, I know that GNOME (either in the time settings or the gnome-tweak-tool application) has a simple check box that allows you to switch from 12-hour to 24-hour time, regardless of the timezone you select.

Is there an upstream bug on the Qt bugzilla for this?  If so, could someone please provide the link?  (Perhaps it is QTBUG-14159 at https://bugreports.qt.io/browse/QTBUG-14159 but that's awfully vaguely worded.)  If not, could someone more knowledgeable about the exact shortcomings of QLocale please open an issue there (and link to it from here), so that those of us who are affected can watch it and vote for it?

(In reply to Christoph Feck from comment #14)
> Just curious, how do GNOME or other desktop users configure their locales?
> Since Plasma 5 now uses the system locale, instead of doing its own thing,
> aren't there any other (non-KDE4) Linux users, that need to customize the
> formats?

Little. XFCE is a mostly-GNOME interface. I have set LC_TIME=en_DK to get me ISO-8601 format and English names for date +%b (used in `ls -l`) at the same time.

As for the task panel clock, its settings dialog suggests a handful of defaults based upon the *language in LC_MESSAGES* (stupid, eh). For example, setting it to de_DE yields the date plugin offering a Choice control {"1999-12-31", "1999 Dezember 31", "12/31/1999", "Dezember 31, 1999", "Dez 31, 1999", "Freitag, Dezember 31, 1999", "Fr, Dez 31, 1999", "31/12/1999", "31 Dezember 1999", "31 Dez 1999", "Freitag, 31 Dezember 1999", "Fr, 31 Dez 1999", "Custom…"}. Do note how it misses lacks offering the default date representation (as output by `date`) and date +%x, which would show the German dot ("31. Dez(ember) 1999").

Anyway, I don't care about the defaults so much because I chose Custom to input my own strftime string, because I like it to be very terse in the panel, but also with a week number. (So I have e.g. %V, %a %-d and %-H in it, which is anything but standard ;-)

Thinking about it, I am not entirely sure customization of locale formats should be implemented in Qt.

QLocale simply respects the system's or user's locale settings. Why should customizations to formats only be respected by Qt applications? This would result in a similar inconsistency we had with KDE4, where only KDE applications respected them, but no other applications, or where users expected KDE applications to follow the standard locale variables, but KDE4 had its own idea. See bug 134993, bug 308674, bug 211531 and certainly many others. It was one of the reasons to drop the KLocale classes.

To me, locale files should be user editable. Then someone could write a tool to edit those settings. I am not familiar with internals of system locale files provided by glibc, though.

For example, I also hate how KCalc now displays numbers in "1.000.000" format, instead of "1 000 000" when enable digit grouping, but German locale simply defaults to a dot for thousands separators, and I really would love to get this addressed everywhere, not just in KCalc.

*** Bug 335949 has been marked as a duplicate of this bug. ***

*** Bug 346759 has been marked as a duplicate of this bug. ***

Well, there doesn't even seem to be a uniform setting.

I did a fresh install of Kubuntu 15.04 and added the Kubuntu Team 5.3 Beta PPA.

In the region settings I selected:

Region: US/American English  --> Because I don't want the system language to be German

[checked ]Detailed Settings
Numbers: Switzerland de_CH
Time: Switzerland de_CH
Currency: Switzerland de_CH
Measruements Units: Switzerland de_CH
Collation and Sorting: Switzerland de_CH

The result is this:

http://images.sjau.ch/img/1fb57908.png

- System clock shows nicely time and date format as I want it: HH:ii  dd.mm.YYYY

- However in Dolphin date entries show:  mm/dd/YY hh:ii am/pm

- And in the terminal it's even more weird. There, the interface language is German.

- Also Gimp presents the interface in German

Would it be possible to have a dialog that would allow creating a custom format like in the KDE4?

Behind the curtain, a custom locale would be created for that custom format and used by the system.

This is basically the workaround that is currently proposed.

Also, there is no way to know which region has the format you are looking for (assuming one exists).  The user has to try them all until they find one that is good enough.  And this requires a reboot after each change.  I don't expect any but the most determined to try that hard.

*** Bug 346906 has been marked as a duplicate of this bug. ***

I want to add that this has to go farther than the date format and I would like to see the full customisability of KLocale returned to KDE. This includes things like being able to set 12/24-hour clocks, change the first day of the week, number digit grouping, negative number formatting, etc.

One of the things that put me off GNOME was how it used this locale-based system instead of letting users decide for themselves what format they wanted to use. My preferences are a mix of Canadian, British and ISO standards, so it's simply not possible to even figure out which country uses the particular standard that I want to use.

Whilst I appreciate that KDE programmers are doing their best, most of us are not clever programmers like you. This UX regression loses a major KDE selling feature that we can't tackle ourselves. I just want to emphasise that I don't want to wait 10 years before this functionality returns!

(In reply to Kevin Clevenger from comment #37)
You can do this for the digital clock plasmoid in 5.4.

The use of generic regions instead of actual proper configurations places an assumption that everyone in every region has the exact same preferences. I use NL as a location, Irish for most defaults, ISO8601 for times, using 2 clocks (one in UTC and the other in CET). I need to set system to en_DE format for a known thunderbird bug.

Switching the location to en_DK.utf8 (http://kb.mozillazine.org/Thunderbird_:_FAQs_:_Change_the_Date_Format) and doing so on Fedora 20 converted the entire desktop to the Danish Language.

I am switching back to Fedora 21 until this is fixed.

We should assign blame where blame is due. I think it's a good idea for KDE to hook into the underlying locale system, since there were localisation issues between KDE programs and non-KDE programs from KDE using its own localisation system. The problem is that the geniuses at IEEE and/or Linux Foundation decided to bundle the localisation settings by country. We could complain to them that this system is overly restrictive, prejudiced and outdated, but they won't, of course, care.

My suggestion is for KDE to expose the customisation settings in locale(5) for us to specify our own settings that'll hook back into locale. That should allow us the KF4 customisation flexibility whilst using Linux and POSIX's developed systems.

*** Bug 352447 has been marked as a duplicate of this bug. ***

I agree this is a problem for personalization.

The default locales for various countries I feel need to be updated.  As you say, the Canadian official date is now ISO 8601.

If KDE is using the system locale as a default date (which I feel is good) then it may be an option to write a program to edit the system locale instead of depending on QT or setting for the desktop.

It may also be a benefit until there is a better way to add a description for each locale showing the various values of the particular locale or providing a web link to the various values.

A set of ISO 8601 locales may be a good option.

Anyone know where to submit requests for updates for default locales?

Digging deeper into how QLocale works, I now understand that my comment #21 is wrong.

My initial impression was that QLocale uses the POSIX interfaces in glibc to get the locale data. But instead, it uses a built-in database derived from the Unicode CLDR database, which offers more information than POSIX can provide.

Using "localedef" to compile a custom locale would not work for Qt applications. QLocale uses system calls on MacOS and Windows, but not on Unix :(

POSIX really needs to be updated to CLDR standards, so that the CLDR data can be used as a base for "localedef". Then Qt wouldn't need to ship it's own database.

*** Bug 353219 has been marked as a duplicate of this bug. ***

Created attachment 95059 [details]
Crude patch to the en_US locale with hardcoded values

As it does not look like KDE/Qt are providing a true solution soon and I want to be able to upgrade to KDE5 without totally upsetting my users because of these locale problems, I made this crude patch to the en_US locale of Qt5.

It changes en_US to 24h time, YYYY-MM-DD, metric units, a thousands separator of space and a decimal separator of comma. So you can stay with en_US to keep all your shell programs sane and still have nice output in all Qt5/KDE5 programs.

If you want slightly different settings, the patch still might give you some guidance how to do it. I also want to point out the testlocales program which you'll find in util/local_database/testlocales within the qt5-qtbase source. Compile and run it, you can use it to search for locale parts you are interested in to combine them in a patch similar to mine.

another thing that seems to be lost - ability to set locale to a region (to get the defaults for all the settings) and override interface language. pretty much all of the previously available overrides were very useful.

I too would like to use en_GB formats generally, but ISO date format (ISO 8601) as the date format and SPACE for the thousands separator following the general advice from
   BIPM and
   IUPAC described here:
      http://www.bipm.org/en/publications/si-brochure/section5-3-4.html
      http://old.iupac.org/reports/provisional/guidelines.html
These require a thin space (or a space) as the thousands separator to avoid confusion in international use.

The ISO data format and use of a space as the thousands separator are likely to be used in any locale.

It seems like this bug could be split into two feature requests:

1) About 75% of the people here, including the OP, seem to be asking for ISO 8601 support*. This specifies, among other things, a date format of YYYY-MM-DD.

2) About 25% of the people here seem to be asking for freely-configurable date, time, and other locale items support.

In my opinion, this bug should concentrate on adding ISO 8601 support, and another bug should be opened for freely-configurable locale support.

* https://en.wikipedia.org/wiki/ISO_8601

I would agree to that, but don't forget the ISO-8601 time format.

Since this has been pointed out to be a KDE issue, I decided to look at the QT bug reports.  I  only found one that I think may be related.  

There is an open bug report for QT to extend the date formats to support Unicode but doesn't look like it has been worked on for a couple of years.
https://bugreports.qt.io/browse/QTBUG-17107

I made a comment to add ISO-8601 as an option.

If I get told that this isn't the correct bug, then I will create a new one, if I can figure out how as something blocks much of their scripted page from working properly.

(In reply to Robin Laing from comment #63)
> Since this has been pointed out to be a KDE issue, I decided to look at the
> QT bug reports.  I  only found one that I think may be related.  
> 
> There is an open bug report for QT to extend the date formats to support
> Unicode but doesn't look like it has been worked on for a couple of years.
> https://bugreports.qt.io/browse/QTBUG-17107
> 
> I made a comment to add ISO-8601 as an option.
> 
> If I get told that this isn't the correct bug, then I will create a new one,
> if I can figure out how as something blocks much of their scripted page from
> working properly.

There are (closed) bug reports related to this: https://bugreports.qt.io/browse/QTBUG-35692 and https://bugreports.qt.io/browse/QTBUG-49950 .  I don't have high hopes for a Qt-side quick-fix...

It is always wrong to forcibly tie the format of dates, times or whatever else to the region of the world where one lives. Not only there are places were several formats are used by different people, there is also people like me who do not like the particular format used in the region where he lives. It just doesn't make sense, except perhaps to provide default settings.

Unix got this amazingly wrong with the «locale» subsystem. It is sad seeing KDE ditching its previously working preferences (in KDE4) to adopt this obviously broken design.

(In reply to Chris from comment #70)
> As I look now, this bug has 875 votes. That's just the number of people who
> have bothered to find this bug entry and vote on it.  I wonder what
> proportion of users actually do that...
> 
> Since this is not scheduled to be fixed, I'd like to politely ask why. Is
> this not considered a bug? Not an important enough bug?  Are there just
> Insufficient resources to deal with it?  Is it believed to be a reasonable
> compromise in features?  How open are the devs to the possibility that the
> locale system might need another rewrite or reverting a significant amount
> in order to fix it?
> 
> What's the reasoning here?  This would be very important for an outside
> developer to know in evaluating their own level of motivation towards
> working on this.

The explanation as I understand it is that the root of the problem is in Qt and it is either not possible, too difficult, or not viable to fix/work around it above Qt in KDE. Until it gets fixed in Qt, it won't be fixed in Plasma. I am currently living on Kubuntu 14.04 LTS which does not have this issue. At this point, I will probably switch to another distro with a different DE.

> What's the reasoning here?  This would be very important for an outside developer to know in evaluating their own level of motivation towards working on this.

We had issues with KDE applications having it's own idea of locales, instead of respecting what the environment (LC_LANG, LC_ALL, etc.) selected. See the comments avove. KF5 does no longer have a separate KLocale class. We now use Qt's QLocale because it respects those variables.

Unfortunately, no one had the time to work on adding back the ability to configure locales. You could contact the qt-development mailing list or ask John Layt for the status and how you can help.

> I have even removed all KDE-based applications from my systems.

Interesting. Which other desktop offers to customize locales?

Maybe it would save allot of headaches if there was an easy way to change locale system wide.  There are ways to play around but it would be nice if there was an ISO 8601 based locale instead of searching and using some country locale.

For 24 clock, I use en_GB.UTF-8 for LC_TIME

But I still don't have the correct short date.

I found this as a work around and have to try it to see how it works.
https://ccollins.wordpress.com/2009/01/06/how-to-change-date-formats-on-ubuntu/

This is more the official way of doing it.
https://wiki.archlinux.org/index.php/Locale

Maybe it would be better to design a program to change the system locale into a format that people want to use instead of waiting for a way to do it via QT.

(In reply to Robin Laing from comment #74)
> For 24 clock, I use en_GB.UTF-8 for LC_TIME
> 
> But I still don't have the correct short date.

LC_TIME of en_DK (english danish) will give you 24Hr & ISO date in many programs that respect that variable

(In reply to EkriirkE from comment #76)
> LC_TIME of en_DK (english danish) will give you 24Hr & ISO date in many
> programs that respect that variable

en_DK has been discussed multiple times in this thread. The locale is not in the Unicode CLDR database and is therefore not available to QT applications.

I'm now using an alternate clock/calendar widget for the panel  (http://kde-look.org/content/show.php/Event+Calendar?content=175591) which allows to set the date to a format I want. It can show the short day - "Fr 25.09." - and you can use any format for time and date you want, that's enough for me.

Created attachment 99000 [details]
attachment-22055-0.html

As I see it, the problem is the whole locale system which assumes that all
your preferences are based on a single region. This problem is beyond KDE,
and affects the entire UNIX ecosystem.

On Sun, May 15, 2016 at 4:37 PM, Janet via KDE Bugzilla <
bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=340982
>
> --- Comment #80 from Janet <bugzilla@kerridis.de> ---
> I'm now using an alternate clock/calendar widget for the panel
> (http://kde-look.org/content/show.php/Event+Calendar?content=175591) which
> allows to set the date to a format I want. It can show the short day - "Fr
> 25.09." - and you can use any format for time and date you want, that's
> enough
> for me.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>

(In reply to Stefan from comment #81)
> Created attachment 99000 [details]
> attachment-22055-0.html
> 
> As I see it, the problem is the whole locale system which assumes that all
> your preferences are based on a single region. This problem is beyond KDE,
> and affects the entire UNIX ecosystem.

The problem with the 'UNIX ecosystem' is beyond the scope of KDE. Yes it would be nice if there were better ways to universally solve the problem at that level and this would fix this issue and make every single application conform, not just ones that use Qt's library for this.

OS X uses POSIX locales just as Linux does. But just as KDE 4 kept things separate so does OS X. LC_ALL=C generally has no effect on an OS X application, but it does have an effect on grep/etc as would be expected. Although OS X was developed a very long time, I think Apple saw it as necessary to keep these systems separate. It is nice to have a universal standard for all, but the POSIX locale system is too inflexible for this as it is. It has no built-in customisation, only forced conformity. But even so, sometimes applications come with their own way to override locale, even ls. GNU ls has the --time-style argument, like so: --time-style="+%Y-%m-%d %H:%M:%S".

(In reply to tdyzio from comment #84)
> To me, this thing sounds like someone funding KDE5 development is forcing
> the issue against the rest of us.

As far as I can gather, it's rather the opposite. That is to say, without more funding---and for various other practical and well-intentioned reasons---it's generally better when possible to stick with upstream rather than complicating things with additional solutions atop of the upstream stack. Unfortunately in this case, QLocale is pretty dramatically inferior to KLocale for any of us (myself very much included) who can't stand the "correct" date and time formats for our locales and have years-bordering-on-decades of relying on the ability to customize this.

The hope is that someone steps up with usable patches for QLocale, and that the Qt folks accept them. Unfortunately I, like most of the people balking at this regression, don't have anywhere near the programming skill to reasonably provide such code. But lacking that, we wait in perpetuity.

(In reply to Keith Zubot-Gephart from comment #85)

> The hope is that someone steps up with usable patches for QLocale, and that
> the Qt folks accept them. Unfortunately I, like most of the people balking
> at this regression, don't have anywhere near the programming skill to
> reasonably provide such code. But lacking that, we wait in perpetuity.

I am definitely in the same boat. I know enough, but not as much needed to port KLocale to KF5. Further, it also relies on downstream KDE Apps to make use of the new KLocale5 (or whatever you're going to call it) instead of QLocale (after years of kapp owners being told to use QLocale).

Interestingly enough, I also found this email from 2011 on removing KLocale. Had I known what was going to happen, I would have objected back then. http://kde-core-devel.kde.narkive.com/v0Q0HYO4/locale-in-kf5-qt5

It seems like item #4 never happened: "4) QLocale will add support for most if not all the KDE options to their parsers/formatters, as well as some options KDE does not currently support."

could some developer estimate the effort needed to implement eeeverything in qlocale (as per http://kde-core-devel.kde.narkive.com/v0Q0HYO4/locale-in-kf5-qt5) ?

i could chip in a few euros, if there was some crowdfunding initiative...

also, was this (or part of this) offered as a project for gsoc ? was the problem that there was nobody willing to mentor this project ?

(In reply to Gerd v. Egidy from comment #54)
> If you want slightly different settings, the patch still might give you some
> guidance how to do it. I also want to point out the testlocales program
> which you'll find in util/local_database/testlocales within the qt5-qtbase
> source. Compile and run it, you can use it to search for locale parts you
> are interested in to combine them in a patch similar to mine.

Thanks for that, Gerd. However, I have no idea how to start with creating a different kind of locale. The numerical codes in `qtbase-opensource-src-5.7.0/src/corelib/tools/qlocale_data_p.h` are incomprehensible to me; I guess testlocales will help explain them, but I'm not sure how to use this (see below). Could you please point me to a tutorial, or please provide more information? Thanks in advance.

$ qmake testlocales.pro
Info: creating stash file /tmp/qt5-base/src/qtbase-opensource-src-5.7.0/.qmake.stash
$ make
g++ -c -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -g -fno-exceptions -Wall -W -D_REENTRANT -fPIC -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_GUI_LIB -DQT_CORE_LIB -I. -isystem /usr/include/qt -isystem /usr/include/qt/QtGui -isystem /usr/include/qt/QtCore -I.moc -isystem /usr/include/libdrm -I../../../mkspecs/linux-g++ -o .obj/localemodel.o localemodel.cpp
localemodel.cpp: In member function ‘virtual QVariant LocaleModel::data(const QModelIndex&, int) const’:
localemodel.cpp:286:60: warning: suggest parentheses around ‘&&’ within ‘||’ [-Wparentheses]
         || role != Qt::DisplayRole && role != Qt::EditRole && role != Qt::ToolTipRole
            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~
g++ -c -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -g -fno-exceptions -Wall -W -D_REENTRANT -fPIC -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_GUI_LIB -DQT_CORE_LIB -I. -isystem /usr/include/qt -isystem /usr/include/qt/QtGui -isystem /usr/include/qt/QtCore -I.moc -isystem /usr/include/libdrm -I../../../mkspecs/linux-g++ -o .obj/localewidget.o localewidget.cpp
localewidget.cpp:28:22: fatal error: QTableView: No such file or directory
 #include <QTableView>
                      ^
compilation terminated.
make: *** [Makefile:690: .obj/localewidget.o] Error 1

(In reply to sparhawk from comment #90)
> Thanks for that, Gerd. However, I have no idea how to start with creating a
> different kind of locale. The numerical codes in
> `qtbase-opensource-src-5.7.0/src/corelib/tools/qlocale_data_p.h` are
> incomprehensible to me;

Sorry, there is no Howto or similar for this, as it is a "crude patch", just as the name says.

I primarily looked at the source and compared the data that different locales used to find out the settings I wanted. With a bit of trial-and-error I got the result I wanted and that is what is in the patch.

So just look at what locale uses the date format you want, what locale uses the currency format you want and so on. If two or more locales use the same format, then compare what fields are the same for them. This way you'll find out which field is what.

After playing around with patching qtcore and with Gentoo's locale settings, I'd like to share my current solution for achieving something like en_AT on a sinlge-user machine (kinda like a German regionalization).

/etc/locale.gen (run locale-gen afterwards):
de_AT.UTF-8 UTF-8
en_US.UTF-8 UTF-8

/etc/env.d/02locale
LANG="en_US.utf8"
LC_COLLATE="de_AT.utf8"
LC_CTYPE="de_AT.utf8"
LC_MEASUREMENT="de_AT.utf8"
LC_MONETARY="de_AT.utf8"
LC_NUMERIC="de_AT.utf8"
LC_PAPER="de_AT.utf8"
LC_TIME="de_AT.utf8"

It's important to omit LC_ALL, which should lead to an empty definition in the output of "locale".
I left the "Region" box in "Regional Settings"->"Formats" at "No change".
This fixes basically all date/time/currency issues I've encountered.

Of course this will display day & month strings in the regionalization language ("de" in my case).
If you're not OK with such a system-wide change, I recommend to patch the locale_data_p.h file. For me however it was not as simple as mapping the "German/Latin/Austria" onto the "English/Latin/UnitedStates" numbers. Keeping the "lang" column at English "31" generated some strange effects like date strings containing "M06" instead of "June".

Created attachment 100416 [details]
attachment-28177-0.html

That seems surprising to me, since although I find it weirdly difficult to
find a direct list, the CLDR website links in turn to lists that include
"English (Denmark)". On http://www.unicode.org/cldr/charts/29/ they even
say "ICU does not contain all of the data in CLDR" when linking to the ICU
which lists "English (Denmark)", which implies that CLDR is a superset of
ICU. The comment you have linked to does not explain *why* en_DK is not
included in the CLDR database.

On Tue, Aug 2, 2016, 07:54 Erik Quaeghebeur via KDE Bugzilla <
bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=340982
>
> --- Comment #98 from Erik Quaeghebeur <kdebugs@equaeghe.nospammail.net>
> ---
> (In reply to EMR_Kde from comment #97)
> >
> > Interesting, KDE doesnt even support en_DK locale ...
> >
> > Yet, KDE defaults to en_US... so what is it? either you honor the
> locale, or
> > allow us to change it like back with kde4
>
> Already covered earlier in Comment 77:
> https://bugs.kde.org/show_bug.cgi?id=340982#c77
> (Please try and avoid adding to this report about things that have already
> been
> covered…)
>
> --
> You are receiving this mail because:
> You voted for the bug.
> You are on the CC list for the bug.

(In reply to Keith Zubot-Gephart from comment #99)
> That seems surprising to me, since although I find it weirdly difficult to
> find a direct list, the CLDR website links in turn to lists that include
> "English (Denmark)". On http://www.unicode.org/cldr/charts/29/ they even
> say "ICU does not contain all of the data in CLDR" when linking to the ICU
> which lists "English (Denmark)", which implies that CLDR is a superset of
> ICU. The comment you have linked to does not explain *why* en_DK is not
> included in the CLDR database.

en_DK has been added to CLDR versions 28 and newer: http://unicode.org/cldr/trac/browser/tags/release-28/common/main
Apparently, the updated versions of CLDR have not yet been incorporated into releases here.

(At the time of this comment, the current release of CLDR is v29)

Should a new bug be filed to request an update of the CLDR data?

(In reply to nerd65536+kde from comment #100)
>
> Should a new bug be filed to request an update of the CLDR data?

CLDR data is embedded in QtCore, so a bug report here won't help.

I haven't been able to find what CLDR version is embedded, but it seems Qt's plans for dealing with this issue (and others) can be found on their wiki: http://wiki.qt.io/Qt-5-QLocale

(In reply to phma from comment #102)
> I recently upgraded to Xenial Xerus. I tried various locales in System
> Settings and found:
> *Latinoamérica - español latinoamericano (es_419) — this is not in the
> locales available in /etc/locale.gen . If I saw es_419 out of this context,
> I'd think it means "Spanish as spoken by Nigerian scammers".
> *Denmark - English (en_DK) — this is not in the list in System Settings,
> even after I ran locale-gen and made sure that en_DK is available.
> 
> Running with an uninstalled locale causes some problems: Error messages are
> in Spanish, but accented characters are output like "no se encontr\xf3 la
> orden" instead of "no se encontró la orden" (command not found). I can type
> a degree sign in Kwrite if I run it with a real UTF-8 locale, but not with
> the nonexistent en_419.UTF-8.
> 
> I am in the USA and use metric. I'd like to select English or Spanish, with
> the short form date being yyyy-mm-dd, 24-hour clock, A4 paper, decimal
> point, and the week starting on Sunday, regardless of the language. I have
> no trouble understanding decimal commas, but when I have a file of XYZ
> coordinates separated by commas, with decimal points, and no thousands
> separators, and throw it into a spreadsheet which, because of a Hispanic
> locale, is expecting a decimal comma, the result is a mess.
> 
> I'd like to see KLocale reinstated, at least until QLocale is as flexible as
> KLocale.

Yeah, I tried rolling my own locale because I knew that there would be some intransigence on this. And plus they said that it uses the system locale... lo and behold it works with the command line apps, but not with Qt/KDE. 

So I don't know... like I said, if they want to use the system locale, USE it, otherwise give us back KLocale. 

You know the phrase (modified for the younger audiences) "[poop] or get off the pot".

As has been explained before in this thread, the code does not really use the system locales, but a hardcoded list in QtCore. The system locales are only mapped to the hardcoded list. You have to patch and recompile QtCore if you want to add a custom locale.

It would be nice if the system recognized the locale to start with.  One configuration.  BUT, I do agree, on a multiuser system, there has to be recognition of personal choice.

First fix should be to get all the valid local's into the hardcoded QTCore so they are recognized.  Such as "Denmark - English (en_DK)"

I would also add an ISO locale to the mix.  Look at the ISO standard and create the best locale to recognize the standards as posted.

I need ISO for work as that is part of our standards and being enforced more severely.

(In reply to Don Curtis from comment #112)
> (In reply to phma from comment #102)
> > I'd like to see KLocale reinstated, at least until QLocale is as flexible as KLocale.
> 
> My vote is to support this suggestion.

+++

KDE classes have served as inspiration for Qt improvements before, and working something out that works in/for KDE can have this effect again.

Improvements to the locale functionality could also take the form of a framework (preferably Tier 1 I suppose).

A glance at Qt's locale page linked above suggests they've embarked upon a thorough consideration of pros and cons of various approaches which is understandable but will not help speed up the arrival of a solution for Plasma 5 desktops. I'd think that it can only help (them and their thought processes) to have a modernised Qt5-based implementation of the KLocale solution from KDE4.

FWIW: Qt5 and KF5 applications take locale settings from the host on Mac (e.g. dolphin5 uses the desired YYYYMMDD short date format for me); a KLocale class or framework shouldn't introduce regressions there, possibly even be a transparent wrapper.

KDE folks are aware this bug needs to be solved:

« Better support for customizing the locale (the system which shows things like time, currencies, numbers in the way the user expects them) is on our radar as well. In this area, we lost some features due to the transition to Frameworks 5, or rather QLocale, away from kdelibs’ custom, but sometimes incompatible locale handling classes.» -- Sebastian Kügler https://vizzzion.org/blog/2016/10/plasmas-road-ahead/

Well, there *is* a reason why I'm still using Kubuntu 14.04 with its "Plasma 4" desktop and run what's basically a home-brewn Neon5 parallel KF5 install.

No "official" reaction on bug reports means that anyone who feels sufficiently concerned by an issue is not just welcome to propose a fix, but probably also quite free to apply it as long as it doesn't break anything obvious.

But the quote of Sebastian's post above confirms what I wrote based on what I recalled reading: the date/time issue comes from QLocale. I know that the Qt folks are aware of it and from what I understand still debating how to address the issue. It does show that whatever solution KDE might bake downstream from QLocale will probably require patching all sources that now depend on QLocale.

For better or for worse, designing a QLocale child class (KLocale?) that works exactly as it should might go against KDE's approach of how they extend Qt, but it *could* make an acceptable (basis for a) solution for Qt.

Could you please move the general thoughts, complaints and ideas on this to another medium?

Anything that doesn't add technical data (and at this point, for this bugreports, that would be very specific traces, solutions, workaround or patches) just litters this bugreports with data that makes it harder to handle, and decreases the chance that someone picks it up and fixes underlying issues.

Assumptions about project management, priorities, man-power, or simply unhappiness about the state of things do NOT belong into the issue tracker, putting it there makes things worse, not better. (Even if you feel better after venting.)

Just imagine a developer having to sift through all the post, just to find the relevant bits of information buried here. It's not helpful at all. If this issue report becomes uneconomical due to signal to noise ratio, I'll close it and ask to reopen another report, with just the relevant information.

Due to personal time constraints, I skip a post as soon as I get the impression that it's not contributing technical data to to the issue, unfortunately, I can't delete posts, but I surely would if that were possible.


Thanks for the issue-tracker discipline, and please don't take this as a personal offense, it's just stating facts that not everybody may be aware of.

I was't sure if you were following this issue. 

How feasible would it be to derive QLocale to something like a KLocale class that provides the functionality missing from QLocale?

PS: probably not made any easier given that (as far as I can tell) QLocale works as one would expect on Mac (i.e. respecting system settings giving me my desired YYYYMMDD dates etc.) and presumably on MS Windows too.

I've explained that in comment#9 already.

(In reply to RJVB from comment #129)
> PS: probably not made any easier given that (as far as I can tell) QLocale
> works as one would expect on Mac (i.e. respecting system settings giving me
> my desired YYYYMMDD dates etc.) and presumably on MS Windows too.

Despite Apple OS X being a certified UNIX®, it seems that you're indicating that Qt and therefore also KDE are not supporting the POSIX ISO 15897 Locale definition used by Linux and other UNIX® implementations.

(In reply to Sebastian Kügler from comment #130)
> I've explained that in comment#9 already.

That comment explains that *using* KLocale would not be an option. I can understand that, to the extent that QLocale doesn't define the methods that would need overriding as virtual (which I haven't checked but presume isn't the case but it should be possible to make it the case in a potential solution).
My question was about the possibility to derive QLocale into a class that provides the desired behaviour. This issue is clearly not important enough for the Qt guys to invest the required man-hours to fix it, so it might help getting things moving to present a working *complete* solution that's based on what exists currently. And for them too it might actually be an advantage if the solution extends QLocale.

(In reply to Don Curtis from comment #131)

> Despite Apple OS X being a certified UNIX®, it seems that you're indicating
> that Qt and therefore also KDE are not supporting the POSIX ISO 15897 Locale
> definition used by Linux and other UNIX® implementations.

How am I indicating that?
IIRC Apple's locale implementation is based on (and a wrapper of) ICU, and provides the same kind of configurability as Plasma 4 does. That's what I'm using to achieve my desired formats.

Quite simply, we're not looking for a solution, the right solution has been proposed already. Someone needs to sit down and do the work, it's *that* simple. 

(I'm outta here, the amount of useless traffic this bugreport is generating just today is too much for me. I don't have time to work on it right now, anyway.)

(In reply to Sebastian Kügler from comment #135)
> Quite simply, we're not looking for a solution, the right solution has been
> proposed already. Someone needs to sit down and do the work, it's *that*
> simple. 

There's a small difference between a proposed difference and one that only needs to be implemented from full draft, but above all it would have been useful to paste a pointer to that proposal here. Clearly not everyone is aware of its existence.

I found a workaround for this bug on the KDE Community Forum here: https://forum.kde.org/viewtopic.php?f=17&t=134970

The process creates a new digital clock widget placed in the users Home rather than altering the original Digital Clock widget in Root. It does involve a bit of file editing but I can confirm that it does work as I posted on that page here: https://forum.kde.org/viewtopic.php?f=17&t=134970#p376530 (also, note on my post there that I found an extra step was necessary to make it work, possibly because of a later version of Plasma 5).

FWIW after patching the widget for ages, more recently, my workaround has been to install awesome widgets [1], which lets you output any arbitrary command, e.g. date +'…' etc.


[1] https://github.com/arcan1s/awesome-widgets

(In reply to Malte Eggers from comment #1)
> To set your locale to use ISO 8601, you have to set LC_TIME=en_DK.

For anyone doing this on a per-application basis (rather than putting it in $HOME/.profile), there is the problem that the language setting does not get saved with the KDE session.  I have filed a separate issue for this with the session management product: Bug 382764.

Whilst googling in relation to Qt's locale support I came across this:

Locale Support in Qt 5 https://wiki.qt.io/Locale_Support_in_Qt_5 

... which may be of some interest to people who've posted in this thread.

(In reply to Paul from comment #145)
> Whilst googling in relation to Qt's locale support I came across this:
> 
> Locale Support in Qt 5 https://wiki.qt.io/Locale_Support_in_Qt_5 
> 
> ... which may be of some interest to people who've posted in this thread.

The Qt document mentions "ICU" (Open Source -- Unicode License) -- which is a result of work done by Taligent, IBM and Sun (Java).

The Qt 5 paper seems to be a little bit out-of-date:
 * openSUSE Leap has ICU 52 libraries.

 ** The Windows 10 Creators Update has integrated ICU into Windows -- "making the C APIs and data publicly accessible." (original Redmond text).
<https://msdn.microsoft.com/en-us/library/windows/desktop/mt823414(v=vs.85).aspx>

*** Bug 384296 has been marked as a duplicate of this 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

For me the way the date/time is displayed on the panel has always been my pet peeve with Plasma 5. This can now be changed to show the date/time in any way you want (how it always used to be) by installing the "Event Calendar" widget as a replacement for the standard calendar.

The Event Calendar widget has all sorts of extra goodies too. Check it out! :-)

I found his hack that might be helpful, its not a solution by any means, but it is useful until a real solution comes out. 
The things is though, the part about font changes doesn't seem to apply (any ideas on that part?)
https://www.ulduzsoft.com/2017/08/custom-date-configuration-in-kde-plasma-digital-clocks/
I was able to set my date in Leap 15 Tumbleweed to (for example)
      09:00:03
 Wed Sept 20,2018
I had to reboot to get it to come up right  as the killall plasmashell; kstart5 plasmashell; didn't work even if i did an export $(dbus-launch) beforehand, but the date format was honored after rebooting.
After seeing this work, I am wondering why kde cant do this or something along these lines.

I also discovered an add-on widget that allows you to set the date and time format to whatever you want including font size color and bold/nobold. Its called eventCalendar. I have tried it in both Leap 42.3 and Tumbleweed and it works great.
My question is - if this widget can do it why can't KDE in general do it?

Because that widget does its own date/time formatting and does not use Qt or KDE Frameworks classes.

Git commit 235fa8107dabb757d88cd1876309c12cad990207 by Chris Holland.
Committed on 14/01/2019 at 01:53.
Pushed by cholland into branch 'master'.

[Digital Clock] Add ability to set a custom date format string

Adds a new customDateFormat config key which is used when the dateFormat "StringEnum" is set to custom.
Shows a link to the Qt time formatting documentation next to the text field.
Qt doc link and text field are hidden when not set to custom date format.

Differential Revision: https://phabricator.kde.org/D18019

M  +5    -1    applets/digital-clock/package/contents/config/main.xml
M  +8    -6    applets/digital-clock/package/contents/ui/DigitalClock.qml
M  +26   -0    applets/digital-clock/package/contents/ui/configAppearance.qml

https://commits.kde.org/plasma-workspace/235fa8107dabb757d88cd1876309c12cad990207

Please note that this bug is about user-wide date format configuration, not just about the clock applet.

I've been annoyed by this issue as well, but I have found a workaround for the time being if you use English. It involves creating the pseudo-locale en_SE which uses the proper ISO 8601 format but still has months and weekdays in English.

Do the following:

sudo ln -s /usr/share/i18n/locales/en_DK /usr/share/i18n/locales/en_SE
echo 'en_SE.UTF-8 UTF-8' | sudo tee -a /etc/locale.gen
sudo locale-gen

Then you may have to re-login before setting your time format in System Settings to "Sweden - English (en_SE)".

This fixed it for me in Dolphin and other programs, however applications that use the long date format still don't use ISO 8601.

Ideally we need something better than the archaic pre-defined UNIX locales, and this lack of flexibility looks bad compared to Windows and Mac desktops. However I don't really know whose role it is to fix that.

*** Bug 429345 has been marked as a duplicate of this bug. ***

Git commit f0d03c7dd7ae8496714483b73cfab1b1708c6ad3 by Méven Car.
Committed on 24/12/2020 at 00:11.
Pushed by meven into branch 'master'.

Details View: display dates as relative Short dates

M  +17   -4    src/kitemviews/kfileitemlistwidget.cpp
M  +4    -0    src/settings/dolphin_detailsmodesettings.kcfg
M  +28   -1    src/settings/viewmodes/viewsettingstab.cpp
M  +2    -0    src/settings/viewmodes/viewsettingstab.h

https://invent.kde.org/system/dolphin/commit/f0d03c7dd7ae8496714483b73cfab1b1708c6ad3

*** Bug 396135 has been marked as a duplicate of this bug. ***

*** Bug 236311 has been marked as a duplicate of this bug. ***

*** Bug 370365 has been marked as a duplicate of this bug. ***

*** Bug 395450 has been marked as a duplicate of this bug. ***

*** Bug 348071 has been marked as a duplicate of this bug. ***

*** Bug 430275 has been marked as a duplicate of this bug. ***

*** Bug 374410 has been marked as a duplicate of this bug. ***

*** Bug 348069 has been marked as a duplicate of this bug. ***

*** Bug 348068 has been marked as a duplicate of this bug. ***

To my knowledge, fixing this requires one of the following:
1. Change the Qt locale system to support the feature
2. Abandon the-in Qt locale system for this and implement a completely custom system, like the KLocale system we had in the KDE 4 days but moved away from in favor of QLocale

Either one would be a huge amount of work.

I wasn't around for the KDE 4 days, but if I had been, I probably would have been against abandoning KLocale (which could do this) for QLocale (which can't). That switch also introduced Bug 394698, which is the other major annoyance with this KCM.

So in retrospect I personally think that switch may have been a mistake, but what's done is done. Hopefully we can learn from that mistake and do better in the future. Since fixing this is not a trivial task, it will probably take a while and require a senior developer.

(In reply to Nate Graham from comment #182)
> To my knowledge, fixing this requires one of the following:
> 1. Change the Qt locale system to support the feature
> 2. Abandon the-in Qt locale system for this and implement a completely
> custom system, like the KLocale system we had in the KDE 4 days but moved
> away from in favor of QLocale
> 
> Either one would be a huge amount of work.

Isn't this exactly where OOC should make things straightforward if not easy?
Just how much work would it be to clone (inherit) QLocale, merge/port the required functionality from KLocale (which I presume is or was in kdelibs4support at some point) and then (once properly debugged) do a search/replace on all the code in the frameworks, plasma and applications repositories to use the new class instead of QLocale? The amount of change could be huge, but maybe even that would be less than one might think if code using QLocale always imports qlocal.h . In that case, only that header has to be replaced with the new header, and the appropriate `using` expression.


[OT]
WHT happened to BKO? All of a sudden it looks as if designed for someone with a visuomotor handicap and a huge screen?!
[/OT]

Would it really be that much work to resurrect the old KLocale class from kdelibs 3, forward-port it to Qt 5 or 6 and stuff it into a new Framework? Then it would just be a matter of porting applications from QLocale to that Framework. (For some, it might even just be a matter of finding the old porting commit and reverting it, plus adding one dependency to the new Framework.)

The old kdelibs 3 code can be found here:
https://invent.kde.org/unmaintained/kdelibs/-/blob/KDE/3.5/kdecore/klocale.cpp
https://invent.kde.org/unmaintained/kdelibs/-/blob/KDE/3.5/kdecore/klocale.h

Yeah, if anyone wants to bring back KLocale and port everything to it, that would be a path forward.

Or better yet, submit everything upstream to QLocale. That would be even better. IIRC that was what was supposed to happen during the Qt5 timeframe, but it never happened, so we wound up with a crippled QLocale and lost the nice user-friendly KLocale features.

In any similar situation in the future, I would like to extract a guarantee that the code is submitted and accepted upstream FIRST before people port stuff away from it! :)

If this were fixed, it would also likely make it easier to resolve https://bugs.kde.org/show_bug.cgi?id=393956

Hesitant to just add another +1, but this issue is *so* awkward. The simple capacity to override default formats with simple standard format codes ought to be trivial for anyone. I just want the logical ISO date format YYYY-MM-DD while keeping other U.S. norms, including 12-hour time (and no, 12-hour is not just some weird American thing, it's how all analog clocks work). I figured out that en_CA for Time works enough, but the extra dots in A.M. and P.M. are silly and take too much extra space. At least that workaround is possible, but this is not how it should be functioning.

People lamenting a *regression* where things were fine and then a new design broke things is not the same as people demanding that free/libre/open software just magically have all the features they wish. And what bug-reporters want is mostly to have the bugs acknowledged completely. There's nothing about Open Source development that makes it any harder to simply say "yes, this is indeed a bad bug". Admitting that it's bad is not the same as a commitment to fix it promptly. There's no room for any comment that tries to be dismissive about the facts of the bug or downplay that it's bad.

The bug is acknowledged. It's marked as CONFIRMED with a VHI ("very high") priority and various technical people have shown up to offer thoughts on how to proceed with resolving it. At this point the best way to make that happen is to let them have that conversation without adding a bunch of comments saying things like, "+1, this is so bad!" and "OMG how did you let this happen?!" "and I've given up hope, KDE sux". Yes, we know it's bad, but clearly there is some desire to fix it among the developers. So let's let that happen.

If you want to express your feelings about how bad this is and urge a quicker resolution, feel free to send them directly to me at nate@kde.org instead of posting a comment.

Thanks.

Well, the thing is, Qt does not actually use the system-wide locales, i.e., glibc/POSIX locales. What it does is map the glibc locale to a Unicode locale and then use that with ICU and/or with bundled copies of Unicode tables within Qt. So just inventing a glibc locale would not fix it, because it would not map to anything in Qt. And the tables in Qt are hardcoded and cannot be extended at runtime.

IMHO, the whole QLocale system should be thrown away / ignored / blacklisted (just like, e.g., QHttp) and KDE code ported to a resurrected KLocale (based on the old kdelibs 3 code, not on QLocale) instead.

Since blaming all of this on Qt is the default: you can actually hire them to implement or change something in Qt.

Personally I think that the fact that KDE is built on Qt doesn't change the fact that Qt =/= KDE, and that KDE would do well to keep thin wrappers for most if not all of its classes that were/are merged into Qt or (will be) replaced by an appropriate Qt class.
The present issue is annoying, but not to the same extent as the equally old QStandardPaths issue on MSWin and Mac, which could also have been avoided much more easily if the old KStandardSomething had been kept around to tweak!

(In reply to hannu.alamaki from comment #118)
> Voting for customizability one way or another. My personal beef is with
> Finnish time format that has changed from sane hh:mm into insane hh.mm.

I find it strange too. Except found out some time ago, that it's now correct https://www.kielikello.fi/-/kellonaikojen-merkitseminen

(In reply to RJVB from comment #203)
> Since blaming all of this on Qt is the default: you can actually hire them
> to implement or change something in Qt.
> 
> Personally I think that the fact that KDE is built on Qt doesn't change the
> fact that Qt =/= KDE, and that KDE would do well to keep thin wrappers for
> most if not all of its classes that were/are merged into Qt or (will be)
> replaced by an appropriate Qt class.
> The present issue is annoying, but not to the same extent as the equally old
> QStandardPaths issue on MSWin and Mac, which could also have been avoided
> much more easily if the old KStandardSomething had been kept around to tweak!

Funny, one of the first things I did for QT was code a date/time picker and color chooser because it was lacking... in '98 :)

The latest discussions about a QT-side change are here: https://bugreports.qt.io/browse/QTBUG-58351

I don't want to jump to conclusions before the discussion has progressed, but I think QLocale may not be the right tool for the job. It is effectively just a string formatting class, but I am not sure Qt will be willing to expand its scope to include formats that are not tied to "locales". They seem pretty married to the "localization" point of view where everything is regions and languages.

Maybe Plasma and the KDE applications should start adding custom formats, or maybe we can revive KLocale. But this comes at the cost of losing consistency with pure Qt and other applications that do not use KDE frameworks.

(In reply to Nate Graham from comment #197)
> The bug is acknowledged. It's marked as CONFIRMED with a VHI ("very high")
> priority and various technical people have shown up to offer thoughts on how
> to proceed with resolving it. At this point the best way to make that happen
> is to let them have that conversation without adding a bunch of comments
> saying things like, "+1, this is so bad!" and "OMG how did you let this
> happen?!" "and I've given up hope, KDE sux". Yes, we know it's bad, but
> clearly there is some desire to fix it among the developers. So let's let
> that happen.
> 
> If you want to express your feelings about how bad this is and urge a
> quicker resolution, feel free to send them directly to me at nate@kde.org
> instead of posting a comment.

To take a different approach: does anyone have an estimate of the amount of money that would be needed to motivate someone with the necessary knowledge to fix this?  If many people are affected by it they might be willing to pay for it.

(In reply to brenbarn from comment #208)
>
> To take a different approach: does anyone have an estimate of the amount of
> money that would be needed to motivate someone with the necessary knowledge
> to fix this?  If many people are affected by it they might be willing to pay
> for it.

I don't think it's only a matter of motivation. It doesn't sound like a concrete path forward has been agreed upon yet.

Per the upstream discussion in https://bugreports.qt.io/browse/QTBUG-58351, this unfortunately isn't something we can feasibly fix in KDE alone. It doesn't even seem like something that can be done in Qt alone! Because the mapping of locales to both string formatting and also translated text is baked into the POSIX and libc implementation of locales, it really needs to be fixed there.

If it's fixed at a level any higher than that, then the result would simply be applications not respecting your formatting preferences in a random-seeming manner. If it was done only in Qt, then all non-Qt apps would be non-respecting, and if we did it in KDE itself (as we did in Plasma 4 and earlier), then all non-KDE apps would be non-conforming, even those that use Qt. It would be a matter of winning the battle but losing the war.

So someone needs to get the ball rolling at the POSIX and libc levels to propose a new spec, or backwards-compatible changes to the existing one.

Is the status supposed to be "resolved upstream"?

Yes, that means it's upstream's job to change/fix/implement/etc. See https://community.kde.org/Get_Involved/Issue_Reporting#Understand_what_the_resolution_statuses_mean

(In reply to John Brooks from comment #211)
> Is the status supposed to be "resolved upstream"?

Yeah, I agree. It's not resolved. People discussing the idea that the best resolution is upstream is not itself resolution nor does it seem that there's consensus on waiting for upstream resolution. It's obviously *possible* (though maybe a bad idea) to create a downstream override.

Again, please see https://community.kde.org/Get_Involved/Issue_Reporting#Understand_what_the_resolution_statuses_mean.

In this context, "RESOLVED UPSTREAM" does not mean, "it's already fixed upstream." It means "It's upstream's job to fix." This is technical terminology;  please don't read the word "RESOLVED" and interpret that to mean "it's already fixed for me personally." That's not what it means. If that's confusing to you, I understand, but re-read https://community.kde.org/Get_Involved/Issue_Reporting#Understand_what_the_resolution_statuses_mean and try to understand that this is a technical context where words sometimes mean something different from their plain English meaning.

As I said, if we do our own thing to fix it for only KDE apps, or only for Qt apps, we make apps' presentation of formats inconsistent across the OS. This would work, but it's not a good solution, especially today given how people use apps form diverse sources. We can't just say, "we'll fix this for KDE or Qt apps and screw everyone else." That's not fair for the user. The user deserves a proper fix that doesn't make anything worse for their 3rd-party apps. That's why it needs to be fixed by overhauling how POSIX locales work.

With this bug remaining unresolved (in the colloquial sense ;)) for nearly a decade now however, doesn't that seem like a matter of letting the perfect be the enemy of the good? It certainly seems like if we're holding out for a change at that low of a level, we'll be holding out forever.

I don't have particularly high hopes for amending POSIX to fix this, to be honest.

(In reply to John Brooks from comment #216)
> I don't have particularly high hopes for amending POSIX to fix this, to be
> honest.

That is why KDE pre-5 (and gnome) did what it did. And could do again.

(In reply to Nate Graham from comment #214)
> As I said, if we do our own thing to fix it for only KDE apps, or only for
> Qt apps, we make apps' presentation of formats inconsistent across the OS.
> This would work, but it's not a good solution, especially today given how
> people use apps form diverse sources. We can't just say, "we'll fix this for
> KDE or Qt apps and screw everyone else." That's not fair for the user. The
> user deserves a proper fix that doesn't make anything worse for their
> 3rd-party apps. That's why it needs to be fixed by overhauling how POSIX
> locales work.

It sounds like what you're saying is, "if we fix it in KDE, it will be broken in non-KDE apps".  But if we don't fix it in KDE, then it will be broken for all apps, including KDE and non-KDE apps.  I would rather have it work the way I want at least some of the time than none of the time.  To say it's "not fair to the user" to have it work some of the time and not all of the time seems a bit disingenuous.  It's also not fair to the user to have it work none of the time.

Also, an alternative I've been exploring is creating a custom locale.  As I understand it, the problem with the Qt system is that they hard-code specific locale information into their own lib.  On the Qt end, that could be changed by, well, having them not do that, and having it draw on a set of locale files in some standard location on the filesystem.  Then what KDE could provide is a "locale editor" program that simply allows the user to input their preferences, and saves that in the form of a custom locale file.  There's no reason for Qt or KDE or POSIX to know or care whether a "locale" file actually corresponds to any country or place; it's just a file that contains settings about how to display things.

The fundamental issue, as I see it, is that for many people these are not "locale" settings.  They are individual user preferences.  People want to set their personal combination of date format, time format, first day of the week, etc., totally independent of any location in the physical world or the jurisdiction of any country.  If POSIX defines that in terms of locales, that is indeed a problem, but the way to get around that is for KDE to give users the tools to fake out POSIX by making their own locale that provides a combination of settings that the user personally prefers.  (I seem to have sort of gotten such a system working using some info I gathered from various places on the web where I found people complaining about this bug, although I'm not sure it's 100% working.)

And what happened to the "there are no [more] KDE apps" (certainly not as opposed to "mere" Qt apps) I got whacked with only a few years back, when the KF5 frameworks were nothing more and nothing less than a set of extensions from which any Qt application could make a pick?

> People want to set their personal combination of date format, time format, first day of the week, etc., totally independent of any location in the physical world or the jurisdiction of any country.

I plead guilty.

A reintroduction of the old KLocale class would have my vote, altering POSIX and/or libc not. If that means changing how the current locale functions work such an overhaul will probably take years before it starts to trickle down to the most adventurous distros and from there into Qt, GTk, KDE etc. I see more promise in developing the updated functionality in a dedicated library.

One issue is that dropping a locale file into a folder for glibc will not be sufficient to fix it, because Qt does not actually use POSIX locales internally, but ICU locales, and has a hardcoded mapping from POSIX to ICU locales. So, for a custom glibc locale to work, Qt would need to be changed to use the POSIX APIs instead of ICU ones, and that would likely mean that POSIX, or at least glibc's implementation of it, would have to grow some additional locale APIs that Qt needs. (Last I checked, the maintainers of the Qt locale codes claimed that the POSIX/glibc locale APIs are not sufficient for their needs.)

I still think that, as I had written in comment #6, KDE should just go back to using a KDE-specific locale and formatting implementation and bypassing the inferior Qt, POSIX, and ICU ones.

(The POSIX, ICU, and Qt implementations are all based on a closed set of locales determining all formatting preferences at country granularity. I do not see that ever changing, because it is a core design principle. And it is a very bad concept, because not everyone in a, possibly large, country agrees on the correct format to use. Even in a small country like Austria, dates can be (and in practice are) formatted as 1.1.2022, 01.01.2022, 1.1.22, etc., currency amounts can be formatted as 12,34€, 12,34 €, €12,34, etc., some people might even want to use 12€34 to match the spoken version, though I do not remember having it ever seen spelled like that. I would expect even more variance in large countries such as the USA.)

Doesn't Qt have to be configured to use ICU, or is that only on non-linux/unix platforms (Mac included)?

ICU uses hardcoded locale definitions?

FWIW, the specialty library approach I mentioned could of course provide suitably amended forks of the ICU and/or libc/POSIX locale functions, which would override those in ICU and/or libc. Doing this carefully enough it should be possible to avoid risk of ODR/ABI issues - I suppose. Heck, the new behaviour could even be conditional on something like an env. variable that "deviant" users like us would have to set. I agree that ICU nor POSIX are likely to change their implementations without a sufficient body of evidence that an alternative implementation is backwards compatible in ABI, API *and* behavioural terms. With enough evidence of demand for an optional different behaviour, however, they could not reject a merge request as introducing unjustified code complexification...

One argument was that if an option is implemented in systemsettings (and not in ICU/Qt/POSIX), then the behaviour of the plasma desktop will be inconsistent with non-KDE applications are going to display differently than GTK/etc. when tuning the date option in systemsettings. This argument applies to plasma desktop, but KDE goes beyond that. I personally use KDE applications but my main system does not use plasma and I think this is a legitimate use case scenario for which the KDE developers should propose a solution. Now let's have a look at the KDE Applications.

* Dolphin supports two date formats: absolute and relative. Changing the setting in dolphin does not impact the KDE File Selection dialogue and other KDE/Qt/GTK software
* Spectacle allows to save files according to the GNU coreutils "date" syntax (by default: Screenshot_%Y%M%D_%H%m%S)
* calligrasheets offers 37 formatting styles for date entries (2 of which are called "System" formats and I presume follow systemsettings)

We can see that KDE application developers are open to add relevant date formatting options when they make sense for their software, even though this could be understood as an inconsistency KDE-wide.

Therefore I think it would be very helpful to implement a free format option in *dolphin* as: 1) dolphin already has 2 options to choose from so it does not change the UI logic or reduce the elegance of KDE software, and 2) spectacle already does something similar. The file manager is a central place where users spend time reading file dates and times, I believe this would help solving a significant fraction of the problem, and alleviate the frustration while waiting for a solution that can be applied to KDE as a whole.

Indeed, the date format in the plasma clock widget is already completely customizable with a field to enter the format code. Everything about that existing is good. Even if system-wide qt-based custom formats were available, being able to independently set the format for the clock display makes sense. It should be the same for time, but it's an outstanding issue: https://bugs.kde.org/show_bug.cgi?id=393956

There is no reason not to support user ability to control formats at multiple levels (program-specific, plasma-overall, and system-wide). Date and time formats have a simple coding, and users should be able to set it.

I urge that this *not* keep the resolved-upstream status even though I acknowledge what it means. KDE can *provide* a KDE-level control for the *display* of dates and times and so on without changing the underlying qt settings. It's not harmful to have both settings exist even later if qt ever fixes their approach to this.

> Indeed, the date format in the plasma clock widget is already completely customizable with a field to enter the format code.

Only if you have it permanently displayed in the tray, which assumes a large enough tray to be readable. The tooltip uses a hardcoded date format that cannot be configured at all.

(e.g., the tooltip shows me today's date as "So. Sep. 25 2022" which is a completely broken format, we do not put the month before the day in Austria)

Thinking more about date format customisation, another option could be a file or a few in .config directory, e.g.:

.config/date-format/default 
.config/date-format/file
.config/date-format/clock
.config/date-format/calendar

Each file would contain a sole strftime format string, or gnu date format string, whatever works best. Which any applications can choose to honour, or ignore (to its users' dismay).

Waiting on POSIX or C standard library can be an exercise in futility. 

Leading by example is contagious. Existing case study is https://editorconfig.org/

(In reply to brenbarn from comment #218)
> It sounds like what you're saying is, "if we fix it in KDE, it will be
> broken in non-KDE apps".  But if we don't fix it in KDE, then it will be
> broken for all apps, including KDE and non-KDE apps.  I would rather have it
> work the way I want at least some of the time than none of the time.  To say
> it's "not fair to the user" to have it work some of the time and not all of
> the time seems a bit disingenuous.  It's also not fair to the user to have
> it work none of the time.

+1 . We can either have a 60% that'll be good enough most users soon, or a 100% solution never, and it seems that some people are saying "Let's wait for the impossible to not happen."

(In reply to Jeremy/starcraft.man from comment #8)
> Nobody wants
> to see their clocks or currency or decimals in a format other than what they
> expect. Some countries even have multiple standards due to regional/language
> differences... Canada's got its own Wikipedia page on it!
> http://en.wikipedia.org/wiki/Date_and_time_notation_in_Canada

In addition to the fact that POSIX has invented and enforced standards that don't exist in countries, it's even worse for people like me who want to use their own standards.  I set my dictionaries to UK because I use the King's English. I use UK date formats because they're cleaner than North American formats, but, unlike Europe, I start my week on a Sunday as the Abrahamic God intended. My functional and reporting currency is CAD $, not GBP.

There is no POSIX standard that will ever accommodate me because of how I mix and match formats. Furthermore, over 20% of people living in Canada were not born in Canada, which means that they are probably used to using other formats that aren't "Canadian" (which, I said earlier, isn't even defined). To say nothing of any Canadian born before 1960 who grew up in school learning Imperial weights and measures instead of Metric.

Point is, even if KDE somehow managed to 'fix' the POSIX standard, it still wouldn't work for most people!

Just adding another data point:

(In reply to Nate Graham from comment #214)
> […]
> As I said, if we do our own thing to fix it for only KDE apps, or only for
> Qt apps, we make apps' presentation of formats inconsistent across the OS.
> […]

In corner cases, it already *is* inconsistent.

I was desperately trying to find a locale where Qt/KDE *and* the rest of my system use ISO date format and 24h time format. I failed. And I now understand why:

(In reply to Kevin Kofler from comment #220)
> […] Qt does not actually use POSIX locales
> internally, but ICU locales, and has a hardcoded mapping from POSIX to ICU
> locales. […]

It seems that mapping is not (and probably cannot be) perfect.

I worked around the problem as follows: It turned out that for Qt/KDE there is the en_SE locale, which provides the format I want, but that locale does not exist in the POSIX world. However, for POSIX the de_BE locale provides the format I want. So I ended up creating an en_SE POSIX locale by simply symlinking en_SE to de_BE and using en_SE system-wide (i.e., in the Qt/KDE world as well as in the POSIX world) for date and time. It is still not perfect because long date format is still inconsistent, but I can tolerate that.

PS: In case this is relevant: I am using Arch Linux.

PPS: If you search for an alternative POSIX locale providing ISO date format, here is a list:

> localectl list-locales | while IFS='' read -r; do echo -n "$REPLY | "; LC_TIME="$REPLY" date -d '2022-01-03 13:02:01' '+%a | %A | %b | %B | %c | %p | %r | %x | %X'; done | grep '| ....-..-.. | ..:..' | column -ts'|'
> 
> csb_PL.UTF-8          pòn     pòniedzôłk     stë      stëcznika        pòn 03 stë 2022 13:02:01                       01:02:01         2022-01-03    13:02:01
> de_AT.UTF-8           Mo      Montag         Jän      Jänner           Mo 03 Jän 2022 13:02:01                        01:02:01         2022-01-03    13:02:01
> de_BE.UTF-8           Mo      Montag         Jan      Januar           Mo 03 Jan 2022 13:02:01                        01:02:01         2022-01-03    13:02:01
> de_LU.UTF-8           Mo      Montag         Jan      Januar           Mo 03 Jan 2022 13:02:01                        01:02:01         2022-01-03    13:02:01
> en_CA.UTF-8           Mon     Monday         Jan      January          Mon 03 Jan 2022 01:02:01 PM            PM      01:02:01 PM      2022-01-03    01:02:01 PM
> en_DK.UTF-8           Mon     Monday         Jan      January          2022-01-03T13:02:01 CET                        01:02:01         2022-01-03    13:02:01
> eo.UTF-8              lun     lundo          Jan      Januaro          lun 03 Jan 2022 13:02:01                       01:02:01         2022-01-03    13:02:01
> fr_CA.UTF-8           lun     lundi          jan      janvier          lun 03 jan 2022 13:02:01                       01:02:01         2022-01-03    13:02:01
> hu_HU.UTF-8           h       hétfő          jan      január           2022. jan. 3., hétfő, 13:02:01 CET             13:02:01         2022-01-03    13:02:01
> lt_LT.UTF-8           Pr      Pirmadienis    saus.    sausio           2022 m. sausio 03 d. 13:02:01                  01:02:01         2022-01-03    13:02:01
> nan_TW.UTF-8@latin    p1      pài-it         1g       1goe̍h            2022 1g 03 (p1) 13:02:01 CET           ē-po͘   01:02:01 ē-po͘   2022-01-03    01:02:01 ē-po͘
> se_NO.UTF-8           vuos    vuossárga      ođđj     ođđajagemánnu    vuos, ođđj  3. b. 2022 13:02:01 CET            01:02:01         2022-01-03    13:02:01
> si_LK.UTF-8           ස       සඳුදා           ජන       ජනවාරි            2022-01-03 13:02:01 +0100              ප.ව.    ප.ව. 01:02:01   2022-01-03    13:02:01
> sv_SE.UTF-8           mån     måndag         jan      januari          mån  3 jan 2022 13:02:01                       01:02:01         2022-01-03    13:02:01
> wae_CH.UTF-8          Män     Mäntag         Jen      Jenner           Män 03. Jen 2022 13:02:01 CET                  01:02:01         2022-01-03    13:02:01

Folks should feel welcome to work on an 80% good solution and see what happens. It's possible it will be considered good enough. But going all the way upstream does seem like the best approach to me. Sufficiently experienced and socially adroit people could definitely make it happen. I've seen it before.

I recently found this bug report after struggling to have suitable units and such in a brand new Plasma install. Going through this, and then going to upstream, has me shaking my head in disbelief.

That this regression happened a *decade* ago, and both KDE and Qt are kicking the can back and forth at each other, is *embarrassing*. You had something that worked previously, why even bother tying this in to a project in a way that so thoroughly breaks user workflow??

Some people are suggesting we go upstream to get them to do something, which strikes me as *delusional*. They clearly said in as many words that this is not their circus and we aren't their clowns. Their suggested "solution" would be tantamount to just rebuilding UNIX from first principles, which is a complete non-starter.

There are some people in this comment thread suggesting that to go back to KDE having their own locale stuff would break it in some non-KDE things. Which, I'm sorry, I've been using linux for 20 years now, since when has KDE *ever* cared about that?? Using KDE apps in a non-KDE environment has always been a pain in the ass and vice versa. Why are you starting to care *now* of all times? Is aggravating users that are neither the devs at their dev laptops nor a hypothetical grandma non-expert user a project goal of KDE?

Either resurrect the old KDE locale methods, or issue a definitive statement that this bug WILL NOT BE FIXED, so I know to stop wasting my time with this project. How embarrassing is it that *Windows* has KDE beat with this?

If this were clear-cut, it would have been done ages ago. Instead we have a trade-off to make:
1. Add the feature for only KDE apps, and then your non-KDE apps will display all their formats incorrectly, or at least inconsistently
2. Stick to the status quo of consistent systemwide formats, but without this desirable feature
3. Attempt to work upstream to change the whole world so that we can have all of the upsides with none of the downsides

You're not wrong that #3 is unlikely, which effectively makes it a #2.

I understand that you personally might prefer #1. However at the moment KDE's developers do in fact want to have KDE's apps play nicely with the world around them. This is far from something we ignore and is in fact a big deal to us. It's why we have a nice-looking GTK theme, a GTK settings synchronization service, a first-class implementation of the portal system for sandboxed apps. It's why we work upstream on wayland protocol work rather than just using private protocols and calling it a day and why we just implemented support in Plasma 6 for the FreeDesktop standard sound theme spec.

You might personally prefer that we had different priorities, and that's fine. We can't make everyone happy. But we can explain our reasoning and hope that people can accept that sometimes there is no ideal solution and we have to pick from among a menu of imperfect options.

(In reply to Nate Graham from comment #235)
> If this were clear-cut, it would have been done ages ago. Instead we have a
> trade-off to make:
> 1. Add the feature for only KDE apps, and then your non-KDE apps will
> display all their formats incorrectly, or at least inconsistently
> 2. Stick to the status quo of consistent systemwide formats, but without
> this desirable feature
> 3. Attempt to work upstream to change the whole world so that we can have
> all of the upsides with none of the downsides

If "upstream" here refers to POSIX locales, then #3 seems out of place.  POSIX locales are not a system for recording or expressing individual user preference, are they?  I do agree that the problem would ideally be fixed upstream with something system-wide, but that "something" may be a project that doesn't exist at present.

(In reply to Nate Graham from comment #235)
> If this were clear-cut, it would have been done ages ago. Instead we have a
> trade-off to make:
> 1. Add the feature for only KDE apps, and then your non-KDE apps will
> display all their formats incorrectly, or at least inconsistently
> 2. Stick to the status quo of consistent systemwide formats, but without
> this desirable feature
> 3. Attempt to work upstream to change the whole world so that we can have
> all of the upsides with none of the downsides
> 
> You're not wrong that #3 is unlikely, which effectively makes it a #2.
> 
> I understand that you personally might prefer #1. However at the moment
> KDE's developers do in fact want to have KDE's apps play nicely with the
> world around them. This is far from something we ignore and is in fact a big
> deal to us. It's why we have a nice-looking GTK theme, a GTK settings
> synchronization service, a first-class implementation of the portal system
> for sandboxed apps. It's why we work upstream on wayland protocol work
> rather than just using private protocols and calling it a day and why we
> just implemented support in Plasma 6 for the FreeDesktop standard sound
> theme spec.
> 
> You might personally prefer that we had different priorities, and that's
> fine. We can't make everyone happy. But we can explain our reasoning and
> hope that people can accept that sometimes there is no ideal solution and we
> have to pick from among a menu of imperfect options.

I don't really understand this logic.  You're saying for users who want things to look a certain way, it's better for them to have everything look bad than to have some look bad and some look good?  KDE can never fix every problem, but what's the use in not fixing something just because doing so would make the unfixed non-KDE stuff look "inconsistent"?

I'd guess Nate is saying that the dev team has decided that consistency is their priority over this bit of usability for some users.
While personally I want this format customisation so bad, I can understand the team having some priorities like that.
Likely, if somebody came up with a patch implementing this, devs would accept it despite the inconsistency. Until that happens...

I think there is a fourth option.

4. Create a ugly hack where each user generates a custom locale for themselves

(In reply to Ken Fallon from comment #239)
> I think there is a fourth option.
> 
> 4. Create a ugly hack where each user generates a custom locale for
> themselves

Which is pretty much what we have. Managed to get something suitable thanks to en_SE and such, but terminal stuff complains about locale all the time now. There's another option, though:

5. Use a different DE that makes concessions to usability.

After this experience on the laptop, for the desktop I switched back to XFCE. Do I have to configure a few things separately for XFCE's clock and Thunar and such? Yeah. But at least it lets me do so without borking my system's locale setup.

(In reply to Nate Graham from comment #235)
> If this were clear-cut, it would have been done ages ago. Instead we have a
> trade-off to make:
> 1. Add the feature for only KDE apps, and then your non-KDE apps will
> display all their formats incorrectly, or at least inconsistently
> 2. Stick to the status quo of consistent systemwide formats, but without
> this desirable feature
> 3. Attempt to work upstream to change the whole world so that we can have
> all of the upsides with none of the downsides
> 
> You're not wrong that #3 is unlikely, which effectively makes it a #2.
> 
> I understand that you personally might prefer #1. However at the moment
> KDE's developers do in fact want to have KDE's apps play nicely with the
> world around them. This is far from something we ignore and is in fact a big
> deal to us. It's why we have a nice-looking GTK theme, a GTK settings
> synchronization service, a first-class implementation of the portal system
> for sandboxed apps. It's why we work upstream on wayland protocol work
> rather than just using private protocols and calling it a day and why we
> just implemented support in Plasma 6 for the FreeDesktop standard sound
> theme spec.
> 
> You might personally prefer that we had different priorities, and that's
> fine. We can't make everyone happy. But we can explain our reasoning and
> hope that people can accept that sometimes there is no ideal solution and we
> have to pick from among a menu of imperfect options.

And this is why Nate is one of the greatest example of a good member of a community. Always respectful and humble, no matter if he disagrees with you. Thank you for being a member if this community Sir! You are definitely making a difference.

Sorry for the "mostly useless" comment, but I think it's important to also show some support for the community members, as a lot of times the negative one are under the spot light.

To be 100% clear, the work that the teams are doing and the amount of time and effort involved is appreciated. 

It is also reasonable to ask for a bug like this to be fixed. If you're not going to fix it then fine. The solution of "RESOLVED UPSTREAM" is not correct when the bug in question is marked at the QT side as "Unresolved". I would suggest INTENTIONAL, or NOT A BUG  would better reflect the status.

As a side note Thunderbird had a similar discussion which is now resolved. https://bugzilla.mozilla.org/show_bug.cgi?id=1509096

My suggestion of a #4 rolling your own was very serious. I would appreciate someone helping me with a beginners guide to creating a custom locale for the different distros.

To be honest I don't understand some of the logic in this discussion.

Are we really asking that KDE changes system's locales, making up some customized/able version? Personally I don't think so.

Several KDE apps provide a kind of TIME INFORMATION. I think we're asking to make this "time information" customizable. As I see it, this doesn't imply any POSIX changes. The system's locales offer several fine-grained variables, like month number or minutes. We're asking that KDE apps allow the users to combine these pieces of time information from the locale in ways that can be convenient for different apps.

For instance, I might want the system-tray clock to show "month-day/hour" with particular separators. Or I might want – for whatever reason – Dolphin to display the time-information column about files only with "year-day".

It's only natural that different apps, for their very nature, may require different choices and display of time information. And the user may want to customize this even more depending on professional use or whatever.

So I don't understand when Nate (https://bugs.kde.org/show_bug.cgi?id=340982#c235) says

"However at the moment KDE's developers do in fact want to have KDE's apps play nicely with the world around them."

What does "play nicely" mean? I don't think we're asking that KDE apps internally store – or share with other apps – locales in any strange ways. We're asking for customizability of how locales info is combined and displayed.

Thunderbird, for example, allows users to display time information in the "Date" column in a user-defined way (https://support.mozilla.org/en-US/kb/customize-date-time-formats-thunderbird). Or, as a different example on the same concept, Emacs let me customize how to display the file-name information, for example displaying "file-name/[last folder in folder tree]". This doesn't mean that Emacs is changing the internal file system.

Why is there so much hang-up about "short-date" and "long-date"? Just let me customize which time data from the locales I want displayed on a Dolphin "Modified" column, for instance.

(In reply to Luca from comment #243)
> We're asking that KDE apps allow
> the users to combine these pieces of time information from the locale in
> ways that can be convenient for different apps.

Yes, thank you for that point so clearly.

There is no reason that I should be unable to enter a custom *presentation* of date or time appropriate to my use of a particular app — independently from the default system locale settings.

However, such *front-end* features (which are appropriate to KDE's ethos IMO) seem like they should be opened for specific front-end use cases. Such as https://bugs.kde.org/show_bug.cgi?id=393956 which is a request to get *time* customization in the clock widget (which already has date customization). That is an open ticket, not marked as resolved, and similar features could be requested (or submitted as patches) in other cases like Dolphin. This ticket here (340982) does seem to be pretty broad and system-level request to customize Locale overall (which I personally *also* think should be possible btw).

(In reply to Aaron Wolf from comment #244)
> However, such *front-end* features (which are appropriate to KDE's ethos
> IMO) seem like they should be opened for specific front-end use cases. 
> This ticket here (340982) does seem to be pretty broad and
> system-level request to customize Locale overall (which I personally *also*
> think should be possible btw).

Thank you for clarifying this ticket's topic to me, I obviously misunderstood!

(In reply to Luca from comment #243)
> To be honest I don't understand some of the logic in this discussion.
> 
> Are we really asking that KDE changes system's locales, making up some
> customized/able version? Personally I don't think so.
> 
> Several KDE apps provide a kind of TIME INFORMATION. I think we're asking to
> make this "time information" customizable. As I see it, this doesn't imply
> any POSIX changes. The system's locales offer several fine-grained
> variables, like month number or minutes. We're asking that KDE apps allow
> the users to combine these pieces of time information from the locale in
> ways that can be convenient for different apps.
> 
> For instance, I might want the system-tray clock to show "month-day/hour"
> with particular separators. Or I might want – for whatever reason – Dolphin
> to display the time-information column about files only with "year-day".
> 
> It's only natural that different apps, for their very nature, may require
> different choices and display of time information. And the user may want to
> customize this even more depending on professional use or whatever.
> 
> So I don't understand when Nate
> (https://bugs.kde.org/show_bug.cgi?id=340982#c235) says
> 
> "However at the moment KDE's developers do in fact want to have KDE's apps
> play nicely with the world around them."
> 
> What does "play nicely" mean? I don't think we're asking that KDE apps
> internally store – or share with other apps – locales in any strange ways.
> We're asking for customizability of how locales info is combined and
> displayed.
> 
> Thunderbird, for example, allows users to display time information in the
> "Date" column in a user-defined way
> (https://support.mozilla.org/en-US/kb/customize-date-time-formats-
> thunderbird). Or, as a different example on the same concept, Emacs let me
> customize how to display the file-name information, for example displaying
> "file-name/[last folder in folder tree]". This doesn't mean that Emacs is
> changing the internal file system.
> 
> Why is there so much hang-up about "short-date" and "long-date"? Just let me
> customize which time data from the locales I want displayed on a Dolphin
> "Modified" column, for instance.

Thank you for putting this in a way I wish I had the patience and eloquence to do! Yeah I sincerely doubt anybody in this decade long thread actually wanted to change the underlying system locale, just display information from it differently in various places in a user defined way. (Which is, funny enough, how a lot of other DEs and programs handle things.)

I know I've been something of a latecomer grouch here, but I too really do appreciate all the work and such that has gone into KDE over the years and all the volunteers contributing what they can. It's this appreciation and love for the whole free software thing that makes bugs like this long-standing one a little more irritating. You don't bother complaining about things you don't really care about, do you? :)

(In reply to Ken Fallon from comment #242)
> My suggestion of a #4 rolling your own was very serious. I would appreciate
> someone helping me with a beginners guide to creating a custom locale for
> the different distros.

The problem is that rolling your own locale is not actually going to work with Qt/KDE applications. See comment #220.

Regarding consistency, just remembered that the digital clock has "date format" dropdown already (https://bugs.kde.org/show_bug.cgi?id=340982#c155 ).
Perhaps eventually the solution is / will be all apps offering their own date/time representation config options. Which might not even be that bad, as the desired format might change depending on the situation.

*** Bug 476048 has been marked as a duplicate of this bug. ***

*** Bug 479477 has been marked as a duplicate of this bug. ***

(In reply to Nate Graham from comment #235)
> If this were clear-cut, it would have been done ages ago. Instead we have a
> trade-off to make:
> 1. Add the feature for only KDE apps, and then your non-KDE apps will
> display all their formats incorrectly, or at least inconsistently
> 2. Stick to the status quo of consistent systemwide formats, but without
> this desirable feature
> 3. Attempt to work upstream to change the whole world so that we can have
> all of the upsides with none of the downsides
> 
> You're not wrong that #3 is unlikely, which effectively makes it a #2.
> 
> I understand that you personally might prefer #1. However at the moment
> KDE's developers do in fact want to have KDE's apps play nicely with the
> world around them. This is far from something we ignore and is in fact a big
> deal to us. It's why we have a nice-looking GTK theme, a GTK settings
> synchronization service, a first-class implementation of the portal system
> for sandboxed apps. It's why we work upstream on wayland protocol work
> rather than just using private protocols and calling it a day and why we
> just implemented support in Plasma 6 for the FreeDesktop standard sound
> theme spec.
> 
> You might personally prefer that we had different priorities, and that's
> fine. We can't make everyone happy. But we can explain our reasoning and
> hope that people can accept that sometimes there is no ideal solution and we
> have to pick from among a menu of imperfect options.

We are on the KDE bugtracker, discussing a KDE problem. The conversation is confined to the field of KDE. Every single user commenting here has stressed the importance of fixing issue 1 (Add the feature for only KDE apps).

I understand the desire to handle issue 3 (Attempt to work upstream to change the whole world) but changing the world is not the goal of the KDE bugtracker nor related software that is developed in conjunction with discussions on the KDE bugtracker.

Please, let issue 1 (Add the feature for only KDE apps) remain the goal of KDE and of this issue specifically, at least until parallel efforts enable fixing issue 3.

We can indeed implement option 1 and fix this issue for KDE apps.

If your perspective is "I would rather have it work the way I want at least some of the time than none of the time", that's valid.

The problem is that if we make this possible to satisfy those people, we're making the system more confusing for people who don't have that preference, or don't even know that that preference is a thing that can exist. 

Gradually we're trying to move away from what I call "broken promise" global options: options that are presented as global in scope but really aren't because they only affect some parts of the system. Experience shows that these options are a recurring source of bug reports from normal users as well as picky technical users who care a lot about consistency.

When we can't fully get rid of kinds of options, we try to add textual explanations, but even those are imperfect. Experience also shows that even if we did something super in-your-face and added a giant banner in the Region & Language KCM that said:

"ALERT! Changing this only affects KDE apps! It will not affect the way dates are expressed in any non-KDE app such as Thunderbird, Firefox, Chrome, LibreOffice, and Blender"

...then I can 100% guarantee you that we would *still* get bug reports from confused users complaining that Thunderbird, Firefox, Chrome, LibreOffice, and Blender don't respect their date display preferences. And we would have to explain the underlying reason over and over again.

So for you folks who want it to at least work some of the time because some is better than none, I understand your perspective, but hopefully you can see how satisfying this preference would make the system less coherent to people without that preference.

(In reply to Nate Graham from comment #253)
> We can indeed implement option 1 and fix this issue for KDE apps.
> 

Thank you. I'm sure that the two hundred people here commenting, and untold frustrated others, appreciate this.

> If your perspective is "I would rather have it work the way I want at least
> some of the time than none of the time", that's valid.
> 

Thank you.

> The problem is that if we make this possible to satisfy those people, we're
> making the system more confusing for people who don't have that preference,
> or don't even know that that preference is a thing that can exist. 
> 

I understand your viewpoint, and I appreciate you conceding that viewpoint to the KDE users who have been begging for this horrible bug to be fixed for years.

> Gradually we're trying to move away from what I call "broken promise" global
> options: options that are presented as global in scope but really aren't
> because they only affect some parts of the system. Experience shows that
> these options are a recurring source of bug reports from normal users as
> well as picky technical users who care a lot about consistency.
> 

Then maybe just label the feature "KDE Date Format" as that is all that KDE can effect. Or even a stand-alone KDE Settings tool (not in System Settings) to make the change, so that no one will complain that it does not affect the entire System.

In any case, that promise is broken already in System Settings in some other places, for instance Windows appearance options do not affect Java nor WXwidgets applications.

> When we can't fully get rid of kinds of options, we try to add textual
> explanations, but even those are imperfect. Experience also shows that even
> if we did something super in-your-face and added a giant banner in the
> Region & Language KCM that said:
> 
> "ALERT! Changing this only affects KDE apps! It will not affect the way
> dates are expressed in any non-KDE app such as Thunderbird, Firefox, Chrome,
> LibreOffice, and Blender"
> 
> ...then I can 100% guarantee you that we would *still* get bug reports from
> confused users complaining that Thunderbird, Firefox, Chrome, LibreOffice,
> and Blender don't respect their date display preferences. And we would have
> to explain the underlying reason over and over again.
> 

Then put the options in a KDE Settings submenu, or a standalone KDE settings application to compliment System Settings. But KDE users need this bug fixed.

> So for you folks who want it to at least work some of the time because some
> is better than none, I understand your perspective, but hopefully you can
> see how satisfying this preference would make the system less coherent to
> people without that preference.

Yes, I see both perspectives. Now which is the lesser evil: KDE applications do not respect cultural date formats and there is absolutely no solution (so KDE apps display their dates wrong), or some people might be confused as to why they need to configure their non-KDE apps' date formats in addition to their KDE date format setting?

I am in general very much for consistency, but being consistently wrong is just not helpful. Even within a country, there can be distinct regional, local, ethnical, or personal preferences, so just having these settings be per country (or per language/country pair for those countries speaking more than one language) just cannot cover it. And many users prefer having their system in English (or some other foreign language), but still expect date formats etc. to follow the rules of their country (but not using its language for weekdays, month names, etc.), which is not covered by the locale system either. So the status quo is frequently not just not according to the user preferences, but genuinely wrong.

Also, there is no consistency anyway, since console and GTK applications use glibc locales, whereas Qt uses ICU locales and only tries to map the glibc locales to those internally. So you end up with en_DK working in everything except Qt applications and en_SE working only in Qt applications, making those popular workarounds for more international-friendly English locales useless. And for the same reason, a custom glibc locale will also not work in Qt applications.

(In reply to Nate Graham from comment #253)
> Experience also shows that even
> if we did something super in-your-face and added a giant banner in the
> Region & Language KCM that said:
> 
> "ALERT! Changing this only affects KDE apps! It will not affect the way
> dates are expressed in any non-KDE app such as Thunderbird, Firefox, Chrome,
> LibreOffice, and Blender"
> 
> ...then I can 100% guarantee you that we would *still* get bug reports from
> confused users complaining that Thunderbird, Firefox, Chrome, LibreOffice,
> and Blender don't respect their date display preferences. And we would have
> to explain the underlying reason over and over again.

To put it bluntly, so what?  Just create a FAQ about it and close those bug reports as invalid.  The fact that people will ask why it doesn't work in all cases doesn't seem like a good reason to not fix it in some cases.

(In reply to brenbarn from comment #257)
> (In reply to Nate Graham from comment #253)
> > "ALERT! Changing this only affects KDE apps! It will not affect the way
> > dates are expressed in any non-KDE app such as Thunderbird, Firefox, Chrome,
> > LibreOffice, and Blender"
> > 
> > ...then I can 100% guarantee you that we would *still* get bug reports from
> > confused users complaining that Thunderbird, Firefox, Chrome, LibreOffice,

> To put it bluntly, so what?  Just create a FAQ about it and close those bug


Remind me why it is again that KDE's systemsettings KCM can't set something that only affects KDE apps and give the user the option to configure the known corresponding setting for non-Qt/KDE applications? KDE4 had something of the sort for the GTk(2) colour profile.

I can see how that would appear impossible if both glib and ICU locales are set from the same environmental variable but every Qt-based application running under `KDE_FULL_SESSION=true` will normally load the platform theme plugin. Would it be too late to change the value of the corresponding env. variable(s) from there and get the intended behaviour?

(In reply to RJVB from comment #258)
> Remind me why it is again that KDE's systemsettings KCM can't set something
> that only affects KDE apps and give the user the option to configure the
> known corresponding setting for non-Qt/KDE applications?
Is there such an option for GTK and/or other toolkits? If there is, then this could be a path forward, since we have a sync service that maps KDE settings to their applicable GTK equivalents already.

(In reply to Nate Graham from comment #259)
> Is there such an option for GTK and/or other toolkits? 

How is that relevant if KDE already has a sync service that apparently does what I'm suggesting? I have no idea what parameter GTk (or Gnome) uses for this particular setting but I can guess that it's the same one KDE is currently setting without the expected effect in Qt-based applications.

As far as I can oversee at this point, all that seems to be needed is to define an additional parameter that defines the behaviour for KDE/Qt applications; this would be the parameter controlled by the KCM. The KDE platform plugin would translate this to the actual parameter used in Qt's internals. That's assuming it gets the chance to do that early enough, of course, but I suppose there must also be a programmatic way to change these settings directly instead of via env. variables.
The KCM can predefine certain mappings from Qt locale definitions to glib ones but since it's probably impossible to foresee every single combination users might require the KCM could provide an optional second locale configuration widget or screen for GTk/Gnome apps.

The only drawback would be that this mechanism doesn't work when running KDE apps under a non-KDE desktop session. It could, if the user sets KDE_FULL_SESSION and KDE_SESSION_VERSION himself, but barring that the proposed mechanism shouldn't change anything for users who are in that situation.

(In reply to RJVB from comment #260)
> (In reply to Nate Graham from comment #259)
> > Is there such an option for GTK and/or other toolkits? 
> 
> How is that relevant if KDE already has a sync service that apparently does
> what I'm suggesting?

The sync service makes use of options and features in the target platform. So if GTK or GNOME apps lack an option to change the date format in the way we want, then there's nothing to sync our date format settings to.

*** Bug 485360 has been marked as a duplicate of this bug. ***

*** Bug 485373 has been marked as a duplicate of this bug. ***

*** Bug 488221 has been marked as a duplicate of this bug. ***

So what's the right workaround for us users while we wait for a 7yo upstream bug to be fixed, that may not even fully solve the problem? There are countless questions about it in all the fora, with mostly conflicting solutions offered. I just want my language + ISO date.

I've tried several things, including a custom locale (https://unix.stackexchange.com/a/204329) which looks sensible except KDE doesn't respect it. To get "Australian-ish" in KDE, in System Settings, I have the Languages set to en_GB above en_US (because en_AU is unknown to it), then individual formats set to Australian, except the date which is Swedish. Apparently the latter disappeared for some time but now it's back (https://superuser.com/q/1162283). I tried en_001 for time formats, too.

My `localectl` output is this:

>System Locale: LANG=en_AU.UTF-8
>               LANGUAGE=en_AU:en_GB:en
>               LC_TIME=en_AU.UTF-8@isodate
>    VC Keymap: (unset)                    
>   X11 Layout: us
>    X11 Model: pc105

KDE cannot/does not use these in a graphical session. Bash in Konsole (& other programs) that would function as desired with those locale settings don't get them. Their envs inherit the mishmash settings from KDE, despite KDE not using glibc locales itself. I looks like KDE sets these env vars though they can point to different translation & localisation resources depending on the program. Examples: Python (notably when using apt) will stumble on the en_001 locale, and `date +%x\ %X` produces "07/03/24 12:55:56" even though KDE assures me that en_SE's short date format is ISO.

I don't change env vars via Autostart's Login & Pre-startup scripts because I think these would interfere with and/or be overridden by the selections in Region & Language that I need for GUI programs.

My virtual terminals are fine. In tty6, I run `locale` and get:
>LANG=en_AU.UTF-8
>LANGUAGE=en_AU:en_GB:en
>LC_CTYPE="en_AU.UTF-8"
>LC_NUMERIC="en_AU.UTF-8"
>LC_TIME=en_AU.UTF-8@isodate
>LC_COLLATE="en_AU.UTF-8"
>LC_MONETARY="en_AU.UTF-8"
>LC_MESSAGES="en_AU.UTF-8"
>LC_PAPER="en_AU.UTF-8"
>LC_NAME="en_AU.UTF-8"
>LC_ADDRESS="en_AU.UTF-8"
>LC_TELEPHONE="en_AU.UTF-8"
>LC_MEASUREMENT="en_AU.UTF-8"
>LC_IDENTIFICATION="en_AU.UTF-8"
>LC_ALL=

But under Konsole I get:
>locale: Cannot set LC_ALL to default locale: No such file or directory
>LANG=en_GB.UTF-8
>LANGUAGE=en_GB:en_US
>LC_CTYPE="en_GB.UTF-8"
>LC_NUMERIC=en_AU.UTF-8
>LC_TIME=en_SE.UTF-8
>LC_COLLATE="en_GB.UTF-8"
>LC_MONETARY=en_AU.UTF-8
>LC_MESSAGES="en_GB.UTF-8"
>LC_PAPER=en_AU.UTF-8
>LC_NAME=en_AU.UTF-8
>LC_ADDRESS=en_AU.UTF-8
>LC_TELEPHONE=en_AU.UTF-8
>LC_MEASUREMENT=en_AU.UTF-8
>LC_IDENTIFICATION=en_AU.UTF-8
>LC_ALL=

I can't override the settings in .profile as shells in Konsole are not login shells. They do read .bashrc but this probably doesn't help any other programs that use glibc locales. I don't know what to do.

The problem with the en_SE workaround is: Qt has en_SE, but no en_DK, whereas glibc has en_DK, but no en_SE.

And that's the most frustrating part of all of this. I tried to roll my own locale years ago because they said "use locale instead, it'll work" but it doesn't! Either roll a klocale or something that allows a user to select their own date time settings or honor a custom locale. (in apple this is easy - of all things Apple - just use the AppleICUDateFormatStrings/AppleICUTimeFormatStrings/AppleIntlCustomFormat). I've had a similar positive date/time experience with older versions of windows (not to sure about more recent).

(In reply to Erec from comment #270)
> Either roll a klocale or something that allows a user to select
> their own date time settings or honor a custom locale. 

I think it must be clear to everyone by now that this is just not going to happen?

This has become comparable to the breakage of (properly functioning of) KDE applications on Macintosh after the 4->5 transition where the old `KStandardDirs` (or some such name) was integrated as `QStandardPaths` in Qt5 but imposed "native" locations on Macintosh (and MS Windows). Qt refused to consider any way to make them compatible with XDG locations, and KDE never bothered to update the build system to use non-XDG locations on "non-XDG platforms".

Qt's argument there was "we have to respect the Apple and Microsoft app store rules"; that's probably moot for platforms that can run full KDE desktops so it might be possible to pay Qt to fix the bug. Or someone can implement the necessary changes and try to jump through the loops of getting it accepted via Gerrit.

In the meantime there's always the option to find another DE that works acceptably and figure out how to use KWin as the window manager (or compositor under Wayland). Exactly what I'm doing on this (older) system that still has KDE Plasma4 installed.

*** Bug 497514 has been marked as a duplicate of this bug. ***

Thanks Nate.

I posted here rather than just adding myself to the CC list, to mention military 'locales' especially, since it hasn't come up here yet. I feel like military formatting is both 
a) a good reason to look at this since the userbase is both colossal and critically important
b) potentially a strong source of funding or other required resources
So I mentioned it to try to have a positive impact here. 

I'm not super bothered by this, it didn't take me long to figure out how to get the system into an adequate approximation. It's a minor annoyance, it's taken a couple years to even mention it.

I'm already tracking that other bug as an interim measure, but I'm looking for a way to tell my computer that I use 'this' time and date format and language, in general, so it appears that way everywhere I look, like in dolphin, or firefox, or ls -l in a TTY or Konsole. Any of those would be better than none, though. 

I understand this is resting on upstream for now, so I'm cool to wait.

https://unicode-org.atlassian.net/browse/CLDR-990 ;( 19 years. :D

(In reply to Nate Graham from comment #277)
> short of re-engineering the entire world

That seems absurd, I know, but no less so than leaving the entire world broken for all time. (get it "all time" XD someone had to do the Dad joke)

Could I help with that other bug? Like, is there a dev working on that? I can't help but imagine that the patch from this thread which added date formatting, could be fairly easily evolved into something which does time the same way. Maybe a good first KDE project? Or my naivete showing?


(In reply to Smittie from comment #276)
> WONTFIX is the reason I abandoned KDE. Not a serious OS for my purposes.

At first, I thought this was a bit aggro, but then I realised you've been posting here for a decade, so... You've earned an opinion.
For every one of these annoyances in KDE there are 10 things I love which don't exist in other DEs. I'm just gonna have to wait this one out. I'm glad you're enjoying Mint though. One of my mates speaks very highly of his Mint machines.

OK, I can use the command
date +"KW%V %A, den %d.%m.%Y"
to get this: KW06 Sonntag, den 09.02.2025
on my debian sid notebook.

No regional code page involved, no local systemwide anti-setting involved, no su involved, no permission by alien race change codepage involved, no breaking systemwide settings involved etc. Yes, language itself is involved (so I get "Sonntag").

So I wonder why KDE cannot use the format tags to do that on a GUI level base.

So i find it funny my first post about this in the comments was 2015... and even MacOS allows you to change the date time formats, via AppleICUDateFormatStrings and have them persist systemwide, yet in KDE, 10 years later, nothing...

(In reply to Erec from comment #280)
> even MacOS allows you to change the date time formats, via
> AppleICUDateFormatStrings and have them persist systemwide

OK, elephant alert.

It's apparently easy to forget or overlook the fact that *KDE is NOT an OS*. It is essentially just a layer around and on top of the actual underlying OS (usually Linux), providing both GUI handles on OS functions and a collection of applications. In other words, a desktop environment (DE), directly comparable to what MS Windows 3 (IIRC!) was.
The Mac OS and MS Windows can do as claimed above because they include such an interface layer, one that is much more tightly integrated with the OS. Those who used Mac OS X 10.3 and earlier will remember that the this interface layer was still hardly more evolved than KDE3 (as far as I'm familiar with that DE). But build a KDE or GTk application for MSWin or Mac, and you'll probably see it obeys its own set of rules.

On Linux, we have roughly 2 DE families: Qt-based and GTk/Gnome-based. Most of the usual-suspect cross-platform applications like the big web browsers or productivity applications like LibreOffice use some version of GTk for their Unix implementations.
And if I'm not mistaken these 2 DE families use different libraries for locale-related operations. 

Up to and including KDE4 all KDE applications still shared some amount of central code that IIRC included a common startup path but also had access to KDE wrappers around "system" functions for a.o. locale operations. That made it relatively easy to ensure consistent behaviour throughout all KDE applications, and an attempt was made to translate KDE settings to the relevant GTk/Gnome settings. That still happens AFAIK, but with KDE5/Qt5 a lot of those KDE convenience wrappers were integrated into Qt or dropped for newly Qt features, both evidently according to Qt's ruleset that aims for a different kind of consistency than the one a (mostly) Linux DE is really interested in.
Nowadays I don't even know the conditions to be considered a "KDE application" - use the KDE build system, conform to KDE UI design rules (if sporting a GUI) and maybe use at least 1 KDE framework (regardless of tier)?

Anyway, this is undoubtedly what Nate referred to when he mentioned rewriting the entire world.

(In reply to RJVB from comment #281)
> (In reply to Erec from comment #280)
> > even MacOS allows you to change the date time formats, via
> > AppleICUDateFormatStrings and have them persist systemwide
> 
> OK, elephant alert.
> 
> It's apparently easy to forget or overlook the fact that *KDE is NOT an OS*.
> It is essentially just a layer around and on top of the actual underlying OS [...]
> 
> Anyway, this is undoubtedly what Nate referred to when he mentioned
> rewriting the entire world.

Thank you for the nice explanation!

Stop *RATIONALIZING* why this is a failure.  Also, the history and comparisons to other operating systems is less then helpful.

We're talking about dates & times.  These are not some rare & obscure tidbits of data that no one has ever heard of.

The fact that some CS student took the time to create a huge, yet incomplete, table to countries and assign the common way that people in those areas like to represent their dates & times might have deserved an 'atta-boy', but there is no way in hell it should have been selected as the only way to choose & represent date & time formats!  The imbecile who approved that deserves to be flogged, or at least removed as a contributor.  Not congratulated or apologized for.  And all the neck-beards that think it's better to be 'socially inclusive' rather than 'technically honest'  need to walk up the stairs out of mommy's basement, get their heads out of their pasty-white asses, and maybe do something useful.

The historical and technical reasons of why things are the way they are have been explained several times in this bug report, and I think that, even if it was apparently news to at least one commenter here, most people here already *know* all this.

However, let me point out that:

* When kdelibs was split into several independent Frameworks, KLocale could easily have become one of those Frameworks instead of getting dropped in favor of the less capable QLocale. That would have allowed KDE applications, or any Qt applications willing to accept one KDE Framework as a dependency, to retain the added flexibility of KLocale.
* Even now, it is not too late to reintroduce a KLocale Framework, either resurrecting and porting the original KLocale code or rewriting it from scratch, and getting Plasma and those KDE Applications (be they Gear or Extragear ones) that display dates and/or times to use it. Third-party Qt applications will then likely follow if they care at all.
* Considering that users are expecting features that KLocale provided and that neither QLocale (Qt/ICU locales) nor POSIX/glibc locales are able to provide, it should be obvious that deprecating KLocale was a mistake and that it needs to be resurrected *now*. This issue report has 133 users on the CC list, 19 duplicates, and 283 comments. This makes it clear that this is a priority for your users.
* Consistency with GTK and other non-Qt applications is a worthwhile goal, but *not* if it means to be limited to the "lowest common denominator" (the intersection of 2 hardcoded lists of locales, one in glibc and one in ICU, which are both neither extensible nor configurable by the end user).

PS: Considering that individually configurable locale formats were available in KDE 3 and 4, your users cannot understand why Plasma 5 and 6 no longer offer this functionality, no matter how often you try to explain the same thing again and again. The fact that KDE 3 and 4 supported this clearly proves that it is *possible*.

(In reply to Kevin Kofler from comment #284)

> * Even now, it is not too late to reintroduce a KLocale Framework, either
> resurrecting and porting the original KLocale code or rewriting it from
> scratch, and getting Plasma and those KDE Applications (be they Gear or
> Extragear ones) that display dates and/or times to use it. Third-party Qt
> applications will then likely follow if they care at all.

There is a more flexible possibility but one that has to be implemented at the Qt level : allow a plugin (e.g. the platform theme plugin) to provide an alternative/extended locale implementation, just as the file dialogs can be altered through a plugin. Even "pure Qt" applications could have their date/time formats determined according to KDE conventions or, in another universe, by GTk/Gnome conventions.

If the military want to pay Qt to implement that, great, let 'em be useful for a change. O:^)

KDE is not a distro, it is a project shipping several things. The main product KDE Plasma is not a distro either, it is a desktop environment.

As far as I know, the other desktop environments, apart from Trinity (fork of KDE 3), do not offer systemwide custom locales either. Any custom date/time format there only affects the desktop environment itself (the clock widget in the taskbar) and no applications (except maybe the file manager if you are lucky), because the applications are typically not part of the desktop environment.

The only desktop environment that has a comparable application selection (coming from the same project) to KDE Plasma is GNOME. And as far as I know, GNOME does not offer such a setting. GNOME generally by design offers as few settings as possible because they believe too many settings confuse users (with which I strongly disagree).

NOTE: If I said something wrong, please point it out and let me know. I am not a native English speaker and I don't know what I said could be “impolite”.

It is now 11 years. I think this should have be actually resolved, not just marking “CLOSED UPSTREAM”. If there is no plan/willing fixing this, please mark it as something like “WONTFIX” “BYDESIGN”. And I am going to show my idea for detail:

If this bug cannot be fixed because whichever consistency, I would like to say:
1. Qt 5/6's QLocale has already broken consistency on Linux(or maybe all POSIX). What QLocale uses is ICU, what worse, it uses a hard-coded ICU↔libc-locale mapping which means it regards en_DK, etc. and user-defined locales as nothing. There are open issues on bugreports.qt.io but it just suggests that Qt would not change using ICU. (maybe libc-locale is unavailable on Windows, or other reason/excuse) So this is not an upstream bug(as they don't think it is a bug).
2. Some applications which uses neither libc-locale nor QLocale, that is their choices. It is unimportant, just leave them alone as it is they who provide configurations for those applications.
3. If this(fixing this bug) could cause inconsistency(between KDE and non-KDE Qt applications), then is Digital Clock, etc. already inconsistent? If you answer no because you think they are using the “locale” by default and custom format needs manual setting, why couldn't providing an item for configuration which uses the “locale” by default and allow manual custom format setting be an option?
4. (maybe unrelated) If you say that KDE is not a distro, then what is XFCE(supports custom date/time format)?

Other words I want to say:
It is the best if systemsettings supports arbitrary date/time format(whatever format is used, like strftime, or Windows-style). If this is thought to be impossible, then please consider use date/time format from libc-locale, at least it supports custom date/time format through custom locale. Just put QLocale away until Qt wants to take responsibility to its inconsistency on Linux. KDE doesn't really need to use everything provided by Qt.

(In reply to junyu336699 from comment #294)

I agree with you. Do you have the URIs to those upstream reports that you reference?

(In reply to Roke Julian Lockhart Beedell from comment #295)
> (In reply to junyu336699 from comment #294)
> 
> I agree with you. Do you have the URIs to those upstream reports that you
> reference?

For which QLocale regards en_DK and user-defined locales as nothing: https://bugreports.qt.io/browse/QTBUG-122216
For which QLocale doesn't provide an interface to customize date/time format: https://bugreports.qt.io/browse/QTBUG-58351

*** Bug 480683 has been marked as a duplicate of this bug. ***

To fix this "properly", I think KDE would need to create a UI for people to customize their formats that would create a glibc locale under the hood, and then Qt folks would need to re-do QLocale to use glibc locales directly, so that all Qt-based software would use the custom locale that you created with the KDE UI.

However it's not clear to me from the Qt bug reports that the Qt folks even want that; they seem interested in remaining with the existing CLDR and ICU-based implementation, which implies that no upstream fix is actually possible here.

Given that…

(In reply to Kevin Kofler from comment #284)
> * Considering that users are expecting features that KLocale provided and
> that neither QLocale (Qt/ICU locales) nor POSIX/glibc locales are able to
> provide, it should be obvious that deprecating KLocale was a mistake and
> that it needs to be resurrected *now*. This issue report has 133 users on
> the CC list, 19 duplicates, and 283 comments. This makes it clear that this
> is a priority for your users.
At this point I think it's worth considering. The challenge is that it would be a ridiculous amount of work.

Maybe we could reach out to the Qt folks to see if there are any small changes to QLocale they'd be willing to accept so we don't have to port away from it. Like maybe there could be an optional "only use glibc locales" mode to unblock a custom glibc locale creation UI. Or a way to create custom Qt-specific locales so at least we could create custom locales that would work in all KDE and Qt apps.

Re-opening, and marking as a wishlist.

Please try to keep the non-technical chatter to a minimum. :)

(In reply to Nate Graham from comment #299)
> At this point I think it's worth considering. The challenge is that it would
> be a ridiculous amount of work.

Would porting KLocale be a ridiculous amount of work?

Lofty as it is to try to provide the same functionality in "pure Qt" applications that's not entirely what the KFi frameworks are about, isn't it?

I haven't really thought over your potential request to make to the Qt guys, so I'll pretend for a second it's not something similar to the mechanism that allows "injecting" a different file open/save dialog. And if indeed not, that might be a change they would be more willing to consider, if not only because it would probably make it easier for other DEs too to provide a "time/date/formats/etc" harmonisation.

OK, this has been a rather lengthy discussion thread now and still no solution?

I was involved somewhere in the countless other duplicates of this issue which I could not yet find again...

I still do not get the point. Not at all.

I have de_DE as my locale and I can change tags for whatever separation string as far as KDE / Qt / locale would let me edit (not that I could, as maybe needed, use ANY letter for separating string, but in the limits of locale anyway). I can send an eMail to someone who has a Chinese locale, and the underlying locale SW would convert my de-settings into a normalized locale string/tag/format which can be understood by the mail SW the Chinese recepient is using (might not be using linux at all, might not be using any "locale" SW at all, but works nevertheless).

So, now that we know the conversion process between different locales works:

Why can't we have a locale named "my_MY" which at first simply is a local (on same computer) copy of an existing locale, such as de_DE here. "my_MY" indicates "my locale", or name it "usr_USR" and introduce a naming convention to identify standard locale from user adjusted locale.

Then use a GUI tool (KDE) to change whatever separation string into which ever time separation string, re-arrange locale time tags to the order you want, change / to . where ever you want, use capital letters vs. small letter where you want - but in the end we do not use anything totally new or introduce anything completely new or re-invent the wheel again. All of this is still valid locale stuff and would not break anything and would not require a new law for anything to introduce it.

For adjusting the tags, letters, order etc. we could use previous KDE tool to do that, just that it would have to be moved to Qt6. This should still blend in fully and be fully compatible with existing locale mechanism. This newly adjusted locale would be used only on my computer, and whenever contacting an external computer, e.g. via eMail, this local locale would be converted to a format the external computer can understand.

So why would this NOT be possible? Why would this involve another endless aligning process between endless entities of locale, Qt, whoever?

Best regards.

(In reply to crptdngl71 from comment #301)
> Why can't we have a locale named "my_MY" which at first simply is a local
> (on same computer) copy of an existing locale, such as de_DE here. "my_MY"
> indicates "my locale", or name it "usr_USR" and introduce a naming
> convention to identify standard locale from user adjusted locale.
> [...]
> So why would this NOT be possible? Why would this involve another endless
> aligning process between endless entities of locale, Qt, whoever?

Completely agree. Something like this is possible with the keyboard layout: in Plasma, if one scrolls through the list of layouts, one finds also the "custom" one. It's an essentially empty layout that the user can change as they please (not straightforward, but it can be done), and then choose in Settings. I know this is a different matter, but they idea of leaving a "custom" choice is great.

(In reply to crptdngl71 from comment #301)

> Why can't we have a locale named "my_MY" which at first simply is a local (on
> same computer) copy of an existing locale, such as de_DE here. "my_MY"
> indicates "my locale", or name it "usr_USR" and introduce a naming convention
> to identify standard locale from user adjusted locale.

The correct language code would be mul-XXX-{$custom_name}, per ISO 639-3:2007(en)
 and ISO 3166-3:2013(en). See https://linguistics.stackexchange.com/revisions/38453/1#:~:text=It%20is%20a%20misconception%20that%20an%20unassigned%20code%20in%20a%20standard%20can%20be%20just%20used%20for%20anything%20you%20want.%20It%20may%20be%20officially%20assigned%20tomorrow!%20This%20is%20unlikely%20in%20the%20case%20of%20ISO%20639%2D1%2C%20but%20this%20is%20the%20way%20standards%20work.

> Then use a GUI tool (KDE) to change whatever separation string into which
> ever time separation string, re-arrange locale time tags to the order you want,
> change / to . where ever you want, use capital letters vs. small letter where
> you want - but in the end we do not use anything totally new or introduce
> anything completely new or re-invent the wheel again. 

Otherwise, the reason for such customisation not being the focus is because if someone wants to adhere to ISO 8601-2:2019/Amd 1:2025, as so many here do, they shouldn't need to locate a suitable string to add to their preferences: it should be a preset. However, in retrospect, your proposal might be a useful basis – better to have it be entirely customisable, then add presets later.

"my_MY" would be Burmese as spoken in Malaysia, which is a combination that does not make much sense and might never be an official glibc locale, but it would still be a blatant abuse to use it for something completely different, and it could have nasty side effects, such as messages appearing in Burmese instead of the language you actually want (because software will fall back from my_MY to the closest locale that it has translations for, which would be my_MM or just my if it has a Burmese translation). So you need to be careful what codes you use for your fake locale!

My C's pretty rusty, but for all the talk of "Don't blame us, we're just using Qt's locale library," the upstream documentation doesn't corrobortae that excuse: https://doc.qt.io/qt-6/qlocale.html . The "Public Types" all accept masks - as they should - not country codes.

The glibc concept of locales is pretty arbitrary and, frankly, wrong. It should die and be put to a hastened death with extreme prejudice. Notwithstanding ISO, I'm not aware of any country in the world (except for maybe the very insecure ones like North Korea) which state, "Shalt thou print the date in dd-mmm-yyyy. No more. No less. dd-mmm-yyyy shalt be the date format thou shalt use, and the format of the date shalt be dd-mmm-yyyy. dd-mmmm-yyyy shalt thou not write, nor either write thou write dd-mm-yy, excepting that thou then proceed to write dd-mmm-yyyy. mm-dd-yy is right out...."

So why don't we use format masks like QLocale and normal people use?

(In reply to Kevin Kofler from comment #304)
> "my_MY" would be Burmese as spoken in Malaysia, 

Thanks for pointing this out.

I chose "my_MY" as an example because of "my" as in "my config", "my locale" etc. to make it easy to remember. I was not intending to abuse, misuse, misconfig something nor make fun of something. It was an example. Maybe we can agree on xx_XX instead or which ever combination is both easy to memorize and recognize.

(In reply to crptdngl71 from comment #306)

> Maybe we can agree on xx_XX instead or which ever combination is both easy to memorize and recognize.

Have you seen https://bugs.kde.org/show_bug.cgi?id=340982#c303?

(In reply to crptdngl71 from comment #306)
> I chose "my_MY" as an example because of "my" as in "my config", "my locale"
> etc. to make it easy to remember. I was not intending to abuse, misuse,

I was afraid of that ... I know it's become common but it's *so* regressive and childish... "my this", "my that" ... mine, MINE, M I N E!!

Plus, it should "your this" and "your that", on anything that resembles or plays the role of a form O:^)

*** Bug 507919 has been marked as a duplicate of this bug. ***