Bug 345378

Thanks for the report

This is available in the "Formats" system settings module. Due to the nature of the underlying technology, we cannot offer anything better at this point.

Right-click the clock -> Set Time Format... -> Time: Select a country that uses 24h clock (like Czech Republic for example). Log out and back in, that should give you 24h clock.

We hope to improve the underlying stuff at some point (Qt/QLocale), but that's all we've got now.

Sorry.

I was coming here to log the same enhancement request as I am in the same position as the author of this. 

Martin, thank you for the workaround - however I only want to change the time format to 24 hours. Every locale I have browsed that offers 24 hours also changes the date format and/or language. What I am looking for is the ability to use a 24 hour clock but keep my date format as MM/DD/YYYY (and in English) and I don't think that is possible now.

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

OK, so which location do I select for a date format of yyyy-mm-dd ?

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

I honestly don't know which location you'd have to select for that.

The good news is that we've discussed this at the Plasma meeting and we're looking into fixing this issue properly (right now we're severely limited by Qt).

That IS good news. 
Hopefully it will be nothing more than convincing the Qt guys to add an ISO 8601 location for time & date. 

Thanks for looking at this!

There was an option in kde4 that allowed you to set whatever time format you wanted, whether it was just hours only or if you wanted am/pm in front of hours, etc. Didn't kde5 switch to qt 5? Did that line of qt remove features?

Yes. More specifically, we switched from KLocale (now deprecated) to QLocale, which never had such features.

Cite: "... to QLocale, which never had such features"

...and none of the KDE developers noticed? And no functional regression check was done as part of the switch?

No, there was a plan to get those into QLocale in time. But the developer(s) never got to finish it for various reasons and now we're stucked in this nomansland.

But there is a replacement solution being worked on, hopefully for 5.4.

>...and none of the KDE developers noticed? And no functional regression check was done as part of the switch?

No, this is KDE. Regressions are a feature, not a bug.  *cough*screensavers*/cough*

(In reply to Martin Klapetek from comment #11)
> No, there was a plan to get those into QLocale in time. But the developer(s)
> never got to finish it for various reasons and now we're stucked in this
> nomansland.
> 
> But there is a replacement solution being worked on, hopefully for 5.4.

Thank you for that explanation! :-)

Can you post a link to the relevant QLocale bug or feature so that we can keep track of its dependency here or even push Qt developers a bit?

I also hope that the "replacement solution" is a real solution and not just a quick'n'dirty hack, or?

In addition, would the new solution enable similar detailed configuration as it was possible with KDE SC 4.x?

I'm not aware of any bug reports; it will be worked on by KDE people afaik.

I'm also not aware of how detailed the settings will be, sorry.

How did this ever get agreed on being implemented like this? I'm not having a go at KDE btw, I realise this comes from further along the chain, so just curious and venting. In my many many years of computing I've never come across settings that tie 12/24 hour clock formats to particular locales. Heck, I've always assumed it was an objective/personal preference. What really irks me is someone spent completely wasted time building this "feature" and that person should be whipped. In the most basic sense, setting A = time format, setting B = date format.. Now forget your geek-orgasm-inducing algorithms and just leave them as is, to be set by the user and no need to match up against a list of what countries use. We humans aren't a smart bunch but we can manage these types of settings.

It should be a KDE philosophy that while you may offer enhanced features, you'll always let the user be in control of. Its a philosophy shown throughout the amazingly good work I still see pumping out of the KDE teams but the whole handling of locale really seems to have been planned, designed and built during an acid-induced weekend of haziness. Who on earth would have agreed to doing this way too as its not just one guys fault.

Its the only thing that spoils latest my Plasma experience. Oh well, that are issues with nm-plasma that I wont go into in this thread.

> In my many many years of computing I've never come across settings that tie 12/24 hour clock formats to particular locales.

Maybe they are the same developers that made my panasonic landline phone that only switches to 24hr time when you set the language to spanish.

> Heck, I've always assumed it was an objective/personal preference

Just like locale is, isn't it... ;)

All I can say is that we're aware of this and there is an ongoing work to fix this. There's no need to further comment on this issue, especially if you have nothing of value to add.

I, too, am here to register my discontent with the current clock
The locale change is impractical at best. Seeing as the en_US locale is the only one that allows the opening of non-Latin filenames while still maintaining an English GUI

For some reason, the files won't open is any of the "locale" command output isn't en_US.UTF-8 (even if it's only Time or Measurement). So I have to be stuck with an AM/PM clock, MM, DD YYYY date, and Imperial units, just to keep the ability to open my non-Latin named files

I am missing the KDE 4 configuration feature, too. I am using the locale "de_DE.UTF-8", but an ISO 8601 date format "YYYY-MM-DD", which I cannot configure anymore with Plasma 5.

Git commit 1fc66aabb2e597fb4b2432a80d4acaa41f305197 by Martin Klapetek.
Committed on 05/08/2015 at 12:25.
Pushed by mklapetek into branch 'master'.

[digital-clock] Add a simple option to use 24h-clock format

In my opinion this is just a temporary workaround and not a very good
one (generally, code-wise it's awesome :P). There should really be a
global config option for that but as we now rely on QLocale and QLocale
is...bad at this, here's at least this small help, which will at least
change the clock format on the panel.

Imo we could really really use something like KLocale again.

REVIEW: 124453
FIXED-IN: 5.4.0

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

http://commits.kde.org/plasma-workspace/1fc66aabb2e597fb4b2432a80d4acaa41f305197

I would really like to be able to customise my date strings, not just have 24hr clock.  Why was this switch done?

@ravenoak: I think this switch is just a temporary least-effort workaround until Qt dev implements the regional/locale/display configuration stuff in a more flexible manner.

The reason for this whole issue is that QT developed those kind of things based on the regional standards and didn't actually account for non-standard or fully-customized display settings (or that was just lower priority from the beginning).

What's the status of this bug?

It's fixed in Plasma 5.4.0

(In reply to Abderrahman Najjar from comment #24)
> It's fixed in Plasma 5.4.0

How is it fixed exactly? I'm using KDE Plasma 5.4.2 and System Settings still only offers country selection in Formats (which picks locale for the whole thing). There is no way to set each of those formats explicitly there.

Right click on clock -> Digital Clock Settings -> Use 24-hour clock.

(In reply to Ancoron from comment #22)
> @ravenoak: I think this switch is just a temporary least-effort workaround
> until Qt dev implements the regional/locale/display configuration stuff in a
> more flexible manner.
> 
> The reason for this whole issue is that QT developed those kind of things
> based on the regional standards and didn't actually account for non-standard
> or fully-customized display settings (or that was just lower priority from
> the beginning).

Is there a bug one could check to see the progress on that work? Thanks.

> Is there a bug one could check to see the progress on that work? Thanks.

Not that I'm aware of. But you can always file one and I'm sure it would get merged with existing one if there is one.

(In reply to Martin Klapetek from comment #1)

> We hope to improve the underlying stuff at some point (Qt/QLocale), but
> that's all we've got now.

It's been more than a year now, and still no fix? I am about to install a new system, and installing KDE5 is still off the table for it. Too bad.

(In reply to EMR_Kde from comment #29)
> (In reply to Martin Klapetek from comment #1)
> 
> > We hope to improve the underlying stuff at some point (Qt/QLocale), but
> > that's all we've got now.
> 
> It's been more than a year now, and still no fix? I am about to install a
> new system, and installing KDE5 is still off the table for it. Too bad.

The issue has been fixed for a while now. I have my settings on US, and my clock in the 24h format through the individual changes in the 'Formats' section of the Regional Settings

Created attachment 98306 [details]
Screenshot of Formats module

Created attachment 98307 [details]
Screenshot of systray & time/date

(In reply to Abderrahman Najjar from comment #32)
> Created attachment 98307 [details]
> Screenshot of systray & time/date

Yeah, but is it system wide, with all KDE apps like with KDE4??

(In reply to EMR_Kde from comment #33)
> 
> Yeah, but is it system wide, with all KDE apps like with KDE4??

Actually no. I filed bug reports for that, but still nothing

Created attachment 98368 [details]
attachment-23796-0.html

what's the # i'll sign up for it

On Tue, Apr 12, 2016 at 4:24 PM, Abderrahman Najjar via KDE Bugzilla <
bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=345378
>
> --- Comment #34 from Abderrahman Najjar <abderrahman.najjar@gmail.com> ---
> (In reply to EMR_Kde from comment #33)
> >
> > Yeah, but is it system wide, with all KDE apps like with KDE4??
>
> Actually no. I filed bug reports for that, but still nothing
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>

Bug 360643. I filed this one specifically for Dolphin, because that's where it's most visible to me

Created attachment 99644 [details]
customizable time/date format hacked plasmoid

Hi there.
I used to have "hh:mm:ss" and "yy-MM-dd ddd" time/date formats in kde4 (kubuntu14.04)
Now the options to set custom format are gone.

For kubuntu 16.04 (not the same version as in GIT) I did a dirty hack to allow custom format of time/date.
Not perfect at all, QML TextField:onEditingFinished() is probably not the right way of doing it, but here you go...

(In reply to Martin Klapetek from comment #1)
> This is available in the "Formats" system settings module. Due to the nature
> of the underlying technology, we cannot offer anything better at this point.

What does "nature of the underlying technology" mean exactly?

Software rules aren't as persistent as physics rules.

In the past, KDE 4 offered a better solution to the problem in the sense that the formats were fully customizable and were independent from the user's location on the planet. KDE 5 took the wrong approach: Instead of providing two panels (simple settings and advanced settings) in "System Settings > Formats", it completely forgot about the advanced settings and provides just the simple settings.

https://www.google.sk/search?q=kde+4+date+time+format

(In reply to Jan Ziak (http://atom-symbol.net) from comment #38)
> https://www.google.sk/search?q=kde+4+date+time+format

Images from the past: https://www.google.sk/search?q=kde+4+date+time+format&tbm=isch

(In reply to Jan Ziak (http://atom-symbol.net) from comment #38)
> (In reply to Martin Klapetek from comment #1)
> > This is available in the "Formats" system settings module. Due to the nature
> > of the underlying technology, we cannot offer anything better at this point.
> 
> What does "nature of the underlying technology" mean exactly?

As explained in my comments above, we have switched
from what you presumably link in your screenshots to
Qt's solution, which was set to contain all the features
you want, but so far it doesn't.

Also as noted above, KDE is fully aware of this issue
and we are fully aware what the options were before,
you don't need to link them to us, really. At this point
it's a resources problem, projects are understaffed and
more pressing issues are being worked on.

Finally, the solution is NOT easy. This WILL have to
go into Qt itself and that means support for all the
platforms Qt supports, which is incredibly complicated
and also partly the reason why it's not done yet.

That said, no need to comment on this further, we know
about this issue and there's nothing that we're able do
about this for now, sorry. Simply adding the same comments
over and over won't magically solve it.

(In reply to Martin Klapetek from comment #40)
> (In reply to Jan Ziak (http://atom-symbol.net) from comment #38)
> > (In reply to Martin Klapetek from comment #1)
> > > This is available in the "Formats" system settings module. Due to the nature
> > > of the underlying technology, we cannot offer anything better at this point.
> > 
> > What does "nature of the underlying technology" mean exactly?
> 
> As explained in my comments above, we have switched
> from what you presumably link in your screenshots to
> Qt's solution, which was set to contain all the features
> you want, but so far it doesn't.
> 
> Also as noted above, KDE is fully aware of this issue
> and we are fully aware what the options were before,
> you don't need to link them to us, really. At this point
> it's a resources problem, projects are understaffed and
> more pressing issues are being worked on.
> 
> Finally, the solution is NOT easy. This WILL have to
> go into Qt itself and that means support for all the
> platforms Qt supports, which is incredibly complicated
> and also partly the reason why it's not done yet.
> 
> That said, no need to comment on this further, we know
> about this issue and there's nothing that we're able do
> about this for now, sorry. Simply adding the same comments
> over and over won't magically solve it.

I don't understand your reply.

In either case, I don't see it as an issue anymore: I patched the underlying Qt code (qlocale.cpp, Gentoo) on my machines. The patch simply modifies QLocale::dateFormat(FormatType)→QString and returns the format string I prefer to use (such as "yyyy-MMM-dd"). I guess I could have also used LD_PRELOAD to modify the behavior of function QLocale::dateFormat(FormatType), but that wouldn't cover the case of compiler inlining the function (within qlocale.cpp, or in case of -flto).

I suggest you submit your patch to Qt then and let the
actual Qt developers comment on that.

(In reply to Martin Klapetek from comment #42)
> I suggest you submit your patch to Qt then and let the
> actual Qt developers comment on that.

There already exist the following functions:

QString QDate::toString(const QString &format) const
QString QDateTime::toString(const QString &format) const

http://doc.qt.io/qt-5/qdate.html#toString
http://doc.qt.io/qt-5/qdatetime.html#toString

Sure, now how would you make every single Qt app
out there know which &format to pass there so that
they all display the same date format? Well, you
wouldn't because this problem is non-trivial.

But you're of course welcome to do your research
and then propose a Qt patch that would allow to
set custom System Locale formats for datetime.
Believe me, if it was that simple, it would have
been done already.

(In reply to Martin Klapetek from comment #44)
> Sure, now how would you make every single Qt app
> out there know which &format to pass there so that
> they all display the same date format? Well, you
> wouldn't because this problem is non-trivial.
> 
> But you're of course welcome to do your research
> and then propose a Qt patch that would allow to
> set custom System Locale formats for datetime.
> Believe me, if it was that simple, it would have
> been done already.

I don't understand what is so complicated about it.

Once I found it is located in qlocale.cpp in QLocale::dateFormat(FormatType)→QString, I am able to _prefix_ (customize) the behavior of the function in any way I can rationally imagine.

For example, it shouldn't be that hard for me to implement per-application (i.e: argv[0]) customization of the FormatType→QString conversion, while having the conversions stored in file "~/.config/by-argv0/qlocale_dateformats.txt". Not that I need it - I am just saying it is doable.

Another example: It shouldn't be that hard to enable transient (i.e: time based) customizations of the FormatType→QString conversion. So for example, if I wanted to customize the behavior of the conversion function just in the header/footer when printing a snippet of C++ source code from KDevelop into PDF file, I can customize the result of the function based on the tuple (argv[0]=="kdevelop", time==aboutNow).

Another example would be to enable temporary adjustments of the behavior based on function names in the backtrace obtained by running "gdb --pid" or by using libunwind.

----

For a dose of creativity, innovation and imagination see for example https://www.youtube.com/watch?v=WwBaeIw8kSQ - Valgelis, the man and his music (1984)

> I don't understand what is so complicated about it.

Exactly. We're talking about a system-wide setting that
will automatically be applied to /all/ Qt applications,
not on per application basis. And ideally should also
include GTK apps but that's for bonus points.

But please, by all means, Qt is opensource, don't let
me stop you from submitting a patch that will provide
an easy way to customize your system datetime format
and thus fix this properly for everybody.

There's no point you arguing your way with me here,
this is an issue that needs to be solved in Qt and I'm
not a Qt developer and I won't solve it here for you.

Feel free to link your Qt discussion/patch here.

(In reply to Jan Ziak (http://atom-symbol.net) from comment #45)
> Valgelis, the man and his music (1984)

Correction: Vangelis, of course.

(In reply to Martin Klapetek from comment #46)
> > I don't understand what is so complicated about it.
> 
> Exactly.

It is possible you might be deeply mistaken on this particular occasion.

> We're talking about a system-wide setting that
> will automatically be applied to /all/ Qt applications,
> not on per application basis. And ideally should also
> include GTK apps but that's for bonus points.
> 
> But please, by all means, Qt is opensource, don't let
> me stop you from submitting a patch that will provide
> an easy way to customize your system datetime format
> and thus fix this properly for everybody.

There is no world-wide micropayment feedback system for compensating open-source contributors yet. It will take at least 20 years for such a system to emerge.

> There's no point you arguing your way with me here,
> this is an issue that needs to be solved in Qt and I'm
> not a Qt developer and I won't solve it here for you.
> 
> Feel free to link your Qt discussion/patch here.

The clock applet has this option now, why is there still discussion about this?

(In reply to Eike Hein from comment #49)
> The clock applet has this option now, why is there still discussion about
> this?

It is probable that the discussion keeps going on here, instead of elsewhere, because the super-bug 354269 is harder to find via the Internet than this sub-bug.

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