I am on Arch with KDE Plasma 6, and the system time is not showing. Nether the digital clock widget nor the lock screen. If someone knows what is wrong please tell me.
1 Like
What have you actually tried, and what went wrong? I’m on artix linux (although with open-rc and not systemd) and the standard digital clock widget works just fine, both on a panel and directly on the desktop. I don’t use a lock screen, so I can’t test that. “It doesn’t work” isn’t much to go on.
1 Like
yep, considering we are many on Arch and everything is fine. I’d say if you chose Arch you 'd better know the basics… before looking for answers and stuff in the KDE - ArchWiki .
Try creating a new User and try again, report back when you’re done.
Arch users are expected to have some basic skills - especially when requesting assistance communication becomes the main one.
We’re able to reproduce the bug in Alternative widgets (plasma 6.1): Only digital clock displays time properly.
Other than creating a new account, you could try to delete the panel and choose default panel after to restore the clock and start fresh.
Is system time ok? Does bios clock the same and, is RTC set to zero = No = UTC
$ date
Sat Jun 8 09:40:34 PM EDT 2024hwclock --show
2024-06-08 21:40:47.338547-04:00
$ timedatectl status
Local time: Sat 2024-06-08 21:40:52 EDT
Universal time: Sun 2024-06-09 01:40:52 UTC
RTC time: Sun 2024-06-09 01:40:52
Time zone: America/New_York (EDT, -0400)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
I didn’t actually expect responses, gave up after the first day LOL.
The system clock is absolutely fine, should have mentioned it in the original post. The digital clock widget is the one that is broken.
The analog clock is also broken, clicking on it to show the calender shows zero.
I deleted the panel, added an empty panel, added digital clock, same problem.
I have only tried removing and readding the widget, and also the entire panel now. Just tried it on a new user and same issue. I regularly run system updates. On another note, the screenshot feature also doesn’t work, so I can’t even show it. Pressing printscreen does bring up the dialog box but it just doesn’t save, or is saving to somewhere that is not the /home/user/Pictures directory.
I created a new user, started X11, which started plasma, and same issue, digital clock is not displaying anything.
Still not sure if this is a plasma issue or a clock issue. Can you install xclock (might be called xorg-xclock) and see if it works (check both analog and digital.) I also can’t tell if you have tried placing the digital clock widget directly on the desktop, rather than on a panel.
Xclock works just fine, adding widget to the desktop does not work either. Running the date command also works just fine. Only the widgets seem to be broken.
For screenshot, FN+PrtSc or PrtSc opens spectacle and the picture goes in home/Pictures (Lenovo).
Is spectacle installed? If not: $ pacman -S spectacle
In add widgets (right click taskbar), if you drag and drop analog clock to desktop, does it display time correctly. Size can be adjusted after.
If you don’t have NVIDIA, you may also try to enable unstable channels to rewrite the system. [extra-testing] is empty and [core-testing] as little: amd-ucode, linux-firmware, systemd 256-1 and few other no so dangerous: -Syu. After restart, enable [kde-unstable] to get a brand-new system.
If you have a restore point in timeshift, you may also try that.
I do have NVIDIA.
Spectacle is installed, pressing printscreen does open up a dialog to let me take a screenshot, only it doesn’t get saved, nor can I copy it. Clicking Save As also does nothing.
I wonder if a conflicting package or shared library could be an issue. I have done a bit of modifications to shared libraries. May have possibly added different versions of libraries to /ust/local/include.
One thing sure you did something that cause this issue. Think Timeshift next time before doing modifications. Rsync works fine with XFS, make sure to select all files: home and root. Ideally, select the restore point from the app and let the process do the work.
You should get plasma 6.1 by the end of next week. Testers will get it next Tuesday or the day after.
For NVIDIA, you may wait until amd-ucode and linux-firmware (20240610) go stable in a few days, but there is no new kernel to deal with: 6.9.3 is the last and is the one you should have.
Even if 6.1 beta is mature now, keep in mind that core-testing will delete the kernel when 6.9.4 will be available. You need a second one to play safe, NVIDIA or not.
Operating System: Arch Linux
KDE Plasma Version: 6.0.90
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.1
Kernel Version: 6.10.0-rc3-1-mainline (64-bit)
Graphics Platform: Wayland
Processors: 16 Ă— AMD Ryzen 7 5825U with Radeon Graphics
timedatectl set-timezone <Your_Timezone>
will generaly solve the problem.
So I have the exact same problem as the OP here. Spectacle can’t save any screenshots, and my digital-clock widget appears to not be displaying time in the taskbar.
I’m running Endeavor OS (6.10.10-zen1-1-zen / Plasma 6.1.5 / Nvidia 560.35.03), and only recently did I notice this issue after upgrading from Linux Zen Kernel 6.8.2 to 6.10.10 and Nvidia 558.58.02 to 560.35.03. I tried upgrading to zen 6.11.1, but had some stability issues, but the issue is still present, and also when downgrading. The only thing I didn’t do was try downgrading the Nvidia drivers.
However, now that I’ve found this post, I tried aerostar666’s suggestion and it actually worked, but only with UTC timezone.
Which promptly after setting it to UTC the clock came back, and spectacle started working again too (likely because it relies on the system time to create the filename). However, now I have another issue. I cannot change the timezone back to my locale. If I do Spectacle stops working again, as does the digital-clock widget.
And if I go into the “Date & Time” settings in KDE, it says “unable to change timezone”.
Also seems that when I run the following timedatectl command it fails:
sudo timedatectl list-timezones
Failed to request list of time zones: Remote peer disconnected
So it seems there is still some troubleshooting I have to do, but wanted to share my findings in-case it helps anyone else that finds this post like I did. 
Timedatectl timeouts are typically a dbus problem.
What is the output of the command :
systemctl status dbus
Please note that timedatectl and systemctl (as far as I can tell) are systemd commands. Some of us (although I admit a decreasing number) do not use systemd, so those comments wouldn’t help us. (I can’t speak for the OP.)
Fortunately/unfortunately, I’m one of those few that uses Systemd. And lucky for me I found a fix this evening!
systemctl status dbus
This output only one failure which was for the ModemManager which I believe I can safely ignore since I am on a desktop PC which does not have a 3G/4G modem in it.
Anyway, what ended up working was after the “list-timezones” command didn’t work I decided to dive deeper into /usr/share/zoneinfo, and it was here that I found the files which configure the various timezones.
Interestingly enouigh after catting out a few of the files in this directory I found quite a few of them were empty. Which I checked my timezone and it was empty, but UTC was not. So at this point I decided to remove tzdata (cached version too) and reinstalled it via Pacman.
sudo pacman -Scc
sudo pacman -Rsn tzdata
sudo pacman -S tzdata
Which at first “sudo timedatectl list-timezones” still produced an error, so I then checked to see if there was perhaps a service that needed to be running, so I found there was “systemd-timedated.service” and "systemd-timesyncd.service " available, which I saw timesyncd was running, and timedated was not. So I attempted to restart timesyncd and then enable/start timedated.
sudo systemctl status systemd-timesyncd.service
sudo systemctl restart systemd-timesyncd.service
sudo systemctl status systemd-timedated.service
sudo systemctl enable systemd-timedated.service
sudo systemctl start systemd-timedated.service
I received an error about timedated.service not needing to be enabled as it is usually called on by another service (timesyncd?), so it shouldn’t be enabled via systemctl, but for whatever reason I ignored that and attempted to run “sudo timedatectl list-timezones” again. This time it output a long list of all of the timezones that were re-populated under /usr/share/zoneinfo by pacman.
❯ sudo timedatectl list-timezones
Africa/Abidjan
Africa/Accra
Africa/Addis_Ababa
...
I was able to verify everything was okay with timedatectl again by using these status commands:
After that bit of success I decided to try running:
sudo timedatectl set-timezone America/Detroit
Which as I had mentioned in my previous post, when I did this before it would set my Calendar month to 0, and have the days set from 1-42, and the digital-clock widget would be blank.
Well, this time it did not do that!
Which I was also able to confirm everything was working with timedatectl using the following commands:
❯ sudo timedatectl status
Local time: Fri 2024-10-04 20:23:38 EDT
Universal time: Sat 2024-10-05 00:23:38 UTC
RTC time: Sat 2024-10-05 00:23:38
Time zone: America/Detroit (EDT, -0400)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
❯ sudo timedatectl timesync-status
Server: 104.156.246.53 (2.arch.pool.ntp.org)
Poll interval: 34min 8s (min: 32s; max 34min 8s)
Leap: normal
Version: 4
Stratum: 2
Reference: CC093677
Precision: 1us (-25)
Root distance: 16.021ms (max: 5s)
Offset: -256us
Delay: 52.910ms
Jitter: 2.769ms
Packet count: 9
Frequency: +9.309ppm
And as a “bonus” I can also now change the timezone from the settings menu via the “Date & Time” section. All of the timezones now have flag icons next to their respective names, and there are comments included too which were not there previously.
So it seems the issue here was some sort of corruption of tzdata. 
Thanks @aerostar666 for replying so quickly on this old thread, I really appreciate the help!
Edit: I’d be curious to know if @Zbquhlhu is using an i9 13900k + Zen Kernel + Nvidia too?
1 Like
@Pink3 I think you may have misread my message. There are fewer and fewer of us NOT using systemd, which is becoming (or has become) the default for most distributions.
Oh, yes I see now. It appears so. My apologies @ostroffjh!