The Digital Clock widget formatting option isn't present any more. Missing field/dialogue to set custom [time + date] formats. (e.g. ddd dd. MMM hh:mm) This was previously available (KDE4?), and is quite a basic feature most users would expect to find available to put in e.g. their panels.
The digital clock's date listing is now completely customizable. > 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 mentioned in https://bugs.kde.org/show_bug.cgi?id=340982#c155 And I can confirm customizing of the date. However, the *time* lacks the comparable field and functions to specify custom time format. (In my case, I want 12-hour time *without* showing the AM/PM part (particularly because I have a left-side panel and much less room for the numbers, so it's too small with the AM/PM shown.)
This is currently possible. Please reopen if I am mistaken.
This is NOT resolved. I'm on the latest KDE Neon user edition. The *date* is fully customizable. The *time* has 3 options: 12-hour, 24-hour, follow-region-setting. None of these are customizable. So, I can't choose to see 12-hour numbers but leave out the AM/PM part (which takes up too much space, and I know whether it is morning or afternoon, I don't need that AM/PM indication!)
To be specific in terms of format, I personally (and I think many others would also) prefer h:mm while still using 12-hour numbers. I don't want the AP or ap part.
Ah my apologies, it's the date format that is fully customisable. I guess that just needs to be extended to the time format so that both can be set however the user wants. On Mon, Jun 14, 2021 at 1:19 AM Aaron Wolf <bugzilla_noreply@kde.org> wrote: > > https://bugs.kde.org/show_bug.cgi?id=393956 > > --- Comment #4 from Aaron Wolf <wolftune@gmail.com> --- > To be specific in terms of format, I personally (and I think many others would > also) prefer h:mm while still using 12-hour numbers. I don't want the AP or ap > part. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
... and I'd like to see seconds in the widget (hh:mm:ss). This should be customizable. Somehow.
I believe this is fixed now. There is an option in KDE 6.x: Show seconds: Never Only in the tooltip Always
(In reply to ezh from comment #7) > I believe this is fixed now. There is an option in KDE 6.x: > > Show seconds: > Never > Only in the tooltip > Always That's not even new. Showing seconds is not the sole purpose of custom time format for the clock. I want to hide the AM/PM part myself because I put my panel on the side, and I don't need to be reminded whether it is evening or morning, and I don't want 24hr. Custom format should work just the same as it already does for DATE: A field where the standard format codes can just be entered so people can decide what the clock display should be. Again, the same exact Digital Clock tool already has an open field for custom date, overriding the format for the system otherwise and just deciding for the clock widget. There's no reason to have the time format not have the exact same flexibility.
*** Bug 486154 has been marked as a duplicate of this bug. ***
at text box for custom should be a bare minimum... there should also be GUI configuration tools as well for those who just want to turn off the am/pm indicators on the 12 hr format it would even be desirable to have a way to set different fonts and colors for time and date parts of the clock display.
Devs, I've been looking for a super simple project as a first contribution to KDE, and it seems as though the above patch for date formatting, could be somewhat easily adapted into doing the same thing, for time, too. I'm not sure if this is a good idea or if anyone is already on the job, so I'm asking: Should I take a run at this?
Absolutely! Jump in the Matrix KDE Development chat and you can ask questions if you get stuck.
Thanks Justin! After reading up on the APIs, it took me literally less than 20 minutes to get this working (speaks highly of the toolchain!), but the implementation details are something I'll need advice on - like, do we care if the settings are backwards-compatible, do we want separate custom formats for the popup and the widget, stuff like that. Ironically, joining the matrix room turns out to be the hard part since my account has been deactivated :D I'll be along shortly...
I can't speak to policies on code or backwards compatibility, I was just excited to see someone wanting to work on this. The Matrix channels will definitely give you the best resources for determining that, #plasma:kde.org would be the best.
Just to set expectations for future users of this here, I have found some limitation to Qt's time formatting: You can't have 12-hour time, without an AM/PM identifier, or 24 hour time, with one. The API returns a time in 24 hour time if there is no AM/PM, or 12 hour if there is one. So for example, if you wanted 10 o'clock at night to be shown as "10:00" or "22:00PM" ... Too bad. You can have "22:00" or "10:00pm" or "10:00PM". Similarly, you can't change the am/pm designator. So like you can have "10.00PM" or "10.00pm" but you cannot have "10.00p" or "10.00 at night" I could work around this through various means but... it's a MASSIVE jump in complexity, not that I mind, but I feel like it's a bad idea. It definitely seems like scope-creep into an artistic clock rather than a utility. I feel like if we really want this, it should be done by enhancing the Qt APIs to support it (after which it would 'just work' here without further changes) So, I guess if you really wanted one of those unusual time formats, please do start now with trying to have it added upstream. Apologies if this is a letdown for anyone. I figure it's unlikely to be a problem, but what do I know ;) Please feel free to speak up if this is a major problem for you. Oh one other thing - if you show milliseconds, it still only updates every ~1 second. I don't see this as a problem really. I mean... lol. I tested it to be sure it wouldn't break, but I don't expect to get that working. Again, if this is a big deal for you, please sing out! PS Thanks again Justin :) I've just found out that I social media so rarely that my matrix account was seen as abandoned and is gone forever, so I'll make a new one and be by in a few hours when the Western Hemisphere is awake :D
I feel I worded that poorly. Just to be clear, there is room for artistic expression here. Like for example, you could totally have things like "35 minutes past 10 pm" or "--35PM10 (EST)--" or whatever. It works with a string as per this document: https://doc.qt.io/qt-6/qml-qtqml-qt.html#formatDateTime-method And has the limitations of the h/hh expressions: h the hour without a leading zero (0 to 23 or 1 to 12 if AM/PM display) hh the hour with a leading zero (00 to 23 or 01 to 12 if AM/PM display) AP use AM/PM display. AP will be replaced by either "AM" or "PM". ap use am/pm display. ap will be replaced by either "am" or "pm".
I understand that the underlying format can't remove the AM/PM with 12-hour. That makes sense because like how could you have a file saying "modified 10:00" without an AM/PM? But for the CLOCK display, because it is the *current* time, it makes sense to remove it. I know it's possible because I ever screwed with a system file and *succeeded* at temporarily suppressing the AM/PM. I think the answer is not to hide it with the format code but to add a simple checkbox "show AM/PM for 12-hour format". When not checked, *accept* the system time character string, but drop the AM/PM part from what is sent to the clock widget to display. I think this is easy enough that someone able to hack on this at all could figure out this step. Again, I got it temporarily once though I wasn't sure what I did (it was a bunch of trial and error and then it got reverted next time I got a plasma update)
(In reply to Aaron Wolf from comment #17) > I think this is easy enough that someone able to hack on this at all could figure out this step. There is no difficulty in figuring it out. The difficulty is that once we do figure it out, it becomes apparent that the only solutions are either, one of various messy hacks, or a wait for upstream - so the best solution is upstream. I am very hesitant to put in work on this, only to deliver an almost-solution and a let-down. That's why I looked into limitations like this (and other things like milliseconds) Still, let us not ignore that this issue has been open for some 7 years now. I would not be sane, to make changes which will *require* a future developer to maintain my spaghetti code. It's obvious that such a developer might not even exist. I'd be creating an unsustainable maintenance burden, and a clock that will break in the future, which I'm sure everyone can agree, is even worse than a clock which lacks a desired formatting option. I do understand that this feature is important to you, so I'll spend some extra time trying to find the least-spaghetti way to deal with it, and see if I can make something practical... but no promises. The official answer from me is "not supported upstream, sorry". I'll see what I can do.
> the only solutions are either, one of various messy hacks, or a wait for upstream - so the best solution is upstream I don't think of it that way in the case of the AM/PM suppression. Almost every single time display across the system NEEDS the AM/PM part just to accurately display time. So, I think the AM/PM suppression for the clock widget doesn't even belong upstream. It's a display issue that only really makes sense in this one case. It's *specifically* the case that a live CLOCK should have this format without AM/PM and *not* the case that any other time presentation would do the same. Thanks for looking into this!
(In reply to Aaron Wolf from comment #19) > It's *specifically* the case that a live CLOCK should have this format without AM/PM and *not* the case that any other time presentation would do the same. Today I spent 30 minutes on the clock widget, and 3 hours of anxiety and hitting delete trying to find a brief and constructive way to reply to this awkward internet argument about how string manipulation libraries should be implemented. This was the result I hope you like it :D
Created attachment 178861 [details] attachment-2227400-0.html i think if the fear is an upsteam update will negate the effort put into you solution, then you only need to look at how long this issue has been open... the upstream change is not coming. and i agree that this is simply more of a display thing than a time function thing, but i appreciate your sense of duty to keep the code as elegant as possible and i hope a solution presents itself to you that you feel is maintainable. we're all rooting for you!! On Tue, Feb 25, 2025 at 3:45 AM pallaswept <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=393956 > > --- Comment #20 from pallaswept <pallaswept@proton.me> --- > (In reply to Aaron Wolf from comment #19) > > It's *specifically* the case that a live CLOCK should have this format > without AM/PM and *not* the case that any other time presentation would do > the same. > > Today I spent 30 minutes on the clock widget, and 3 hours of anxiety and > hitting delete trying to find a brief and constructive way to reply to this > awkward internet argument about how string manipulation libraries should be > implemented. > > This was the result I hope you like it :D > > -- > You are receiving this mail because: > You are on the CC list for the bug.
The TLDR on this is that stripping localised AM/PM indicators from 12-hour time (or from custom formatted time with 12-hour time specified by adding am/pm indicators) is going to happen, but adding them to 24-hour time is not, until Qt provides it. I've also discovered through ensuring I do this right, that the AM/PM indicators are not translated into the local language. I'm going to fix that, too. Shout out to whatever region ar_EG is for helping me test :D Please, take my word for it. The more I look into it the more I'm absolutely certain, this should be done in the library. I could explain it, but it's a long, long, long story. Every time I try and do a short version to explain it to you guys, it is literal pages of text. It's complex. Like really surprisingly complex. I don't wanna argue about it or explain it. I just wanna fix it. The delay on this hasn't been because of a need for an upstream change which is delayed. It's simply that noone has volunteered. The upstream change needs to be requested. Nothing at all that happens here is going to change that. There is a need for this feature, and a clock is just one example.