You are not logged in.
After a recent update my waybar clock stopped displaying time in my local timezone and began displaying in UTC. I did not make any configuration changes myself before the change.
System info:
linux-lts 6.6.50-1
sway 1:1.9-5
waybar 0.10.4-2
$ timedatectl
Local time: Tue 2024-09-10 07:33:05 EDT
Universal time: Tue 2024-09-10 11:33:05 UTC
RTC time: Tue 2024-09-10 11:33:05
Time zone: US/Eastern (EDT, -0400)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
Excerpt from waybar/config
"clock#time": {
"interval": 10,
"format": "{:%H:%M}",
"tooltip": false
},
I tried adding a line for the timezone, i.e. "timezone": "America/Eastern", or "timezone": "" to my config, but neither of those changed the waybar clock after reset. I'm having trouble tracking down what got changed and/or what is determining the output time of the waybar clock. A push in the right direction would be greatly appreciated.
Last edited by psykokura (2024-09-11 10:55:06)
Offline
"America/Eastern" isn't a tzdata timezone. Use "America/New_York", "US/Eastern", or "EST" ... or some other entry under /usr/share/zoneinfo/.
Last edited by Trilby (2024-09-10 14:13:29)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
hi the same problem solution downgrade tzdata package and ignore it in pacman conf working
Offline
same issue. what version of tzdata did you downgrade to?
Offline
The timectl in the OP looks ok, though (on US/Eastern) - I assume "date" also shows the correct time?
It's only waybar?
@nmars, same timezone?
Offline
hi ive downgrated to tzdata-2024a-2-x86_64.pkg.tar.zst
Last edited by nmars (2024-09-10 14:34:30)
Offline
Affecting only waybar and being fixed by a downgrading only tzdata is extrodinarily unlilkely.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
i said what i said no offense maybe unlikely but its working
Offline
There's a ginormous https://archlinux.org/packages/extra-te … 86_64/fmt/ update in testing right now…
Is anyone here *not* using https://archlinux.org/packages/extra/x86_64/waybar/ from the extra repo (but some AUR or the testing repos)?
Is anyone here using any testing repos?
Does anyone here have a wrong timezone/time w/ the "date" or anything but waybar?
Is everyone here in the US/Eastern timezone?
Offline
hi ive downgrated to tzdata-2024a-2-x86_64.pkg.tar.zst
lmao its actually work, thanks bro.
Offline
Hi,
I also noticed this issue with waybar clock only, that is, I can confirm that date command gives the correct output in a shell.
I'm in Central European timezone using waybar from the official repo.
$ timedatectl
Local time: di 2024-09-10 17:26:56 CEST
Universal time: di 2024-09-10 15:26:56 UTC
RTC time: di 2024-09-10 15:26:55
Time zone: Europe/Amsterdam (CEST, +0200)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
$ date
di 10 sep 2024 17:29:40 CEST
Have not tried downgrading or otherwise looking into solving the problem. Just wanted to add my datapoint here.
Offline
Hello,
Another datapoint here. Downgrading works. I also have waybar from official repo. Timezone is Europe/Amsterdam, RTC is in UTC.
Last edited by Earthgame_s (2024-09-10 16:21:05)
Offline
"America/Eastern" isn't a tzdata timezone. Use "America/New_York", "US/Eastern", or "EST" ... or some other entry under /usr/share/zoneinfo/.
Trilby, I apologize, I typed that part from memory and got my wires crossed. I originally had "US/Eastern", but I tried all three that you mentioned after reading your post, it's still showing as UTC after resetting sway. Working off of that I tried manually restarting waybar from a terminal while sway was running and I noticed a warning:
[2024-09-10 13:23:13.341] [warning] Timezone: US/Eastern. std::chrono::tzdb: cannot locate zone: US/Eastern
The output of date is the correct local time:
Tue Sep 10 01:25:19 PM EDT 2024
and I'm using tzdata 2024b-1 from the Core repository and sway from Extra (not testing). Duckduckgo-ing (not very catchy, is it?) the warning didn't give me much to go on. I was inclined to think there was an issue with the database itself, but all of the entries in /usr/share/zoneinfo are there. I tried putting the full path to /usr in my waybar config but that didn't fix it. I'm hesitant to downgrade a package to fix something, especially if I don't know for certain what is causing the behavior...
Last edited by psykokura (2024-09-10 17:42:05)
Offline
I am also seeing this behavior after I did a
pacman -Syu
then reboot last night. As I type this, my local time is 14:05:
$ timedatectl status
Local time: Tue 2024-09-10 14:05:46 EDT
Universal time: Tue 2024-09-10 18:05:46 UTC
RTC time: Tue 2024-09-10 18:05:46
Time zone: America/Indianapolis (EDT, -0400)
System clock synchronized: yes
NTP service: inactive
RTC in local TZ: no
but waybar gives the time as 18:05. My waybar config for the clock:
"clock#2": {
"format": "{:%H:%M}",
"tooltip": false
},
This started right after the update / reboot. I have not seen an incorrect / UTC time anywhere else so far. I am using waybar from extras: https://archlinux.org/packages/extra/x86_64/waybar/
Last edited by robd (2024-09-10 18:12:06)
Offline
That's this issue. There's a fix for it in gcc currently in the core-testing repository. It doesn't affect C applications, which is why date, timedatectl, and others are still showing the correct timezone.
Offline
i said what i said no offense maybe unlikely but its working
I had no issue with what you said. I said what I said ... and I was right. This is not limited to waybar. It would affect anything using C++ std libs and tzdata. Geesh.
Last edited by Trilby (2024-09-10 19:54:23)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
same issue. what version of tzdata did you downgrade to?
I had a-2 on my pacman cache, so that's the one I went for:
sudo pacman -U file:///var/cache/pacman/pkg/tzdata-2024a-2-x86_64.pkg.tar.zst
To avoid any unwanted updates, I added IgnorePkg = tzdata to /etc/pacman.conf, and when I try to update, pacman says (among other things):
:: Searching databases for updates...
-> tzdata: ignoring package upgrade (2024a-2 => 2024b-1)
Once the new version comes out and I know for a fact it works I'll update it. Until then, it's working fine.
Last edited by taflaj (2024-09-10 23:29:26)
Offline
Apparently it's been fixed in a gcc commit. If you're upgrading your system (with tzdata aswell) waybar should be fine again: https://gitlab.archlinux.org/archlinux/ … 5bd1741737
Offline
Its working for me after the new update (tzdata 2024b-2)
Offline
That's this issue. There's a fix for it in gcc currently in the core-testing repository. It doesn't affect C applications, which is why date, timedatectl, and others are still showing the correct timezone.
The update resolved it. Thank you to everyone for adding insight. It's always great to know the reason behind the issue, especially something like this where it didn't seem to affect the rest of the system.
Offline