[SOLVED] Waybar clock showing UTC instead of local

psykokura · 2024-09-10 11:43:24

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)

Trilby · 2024-09-10 12:57:47

"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)

nmars · 2024-09-10 13:03:18

hi the same problem solution downgrade tzdata package and ignore it in pacman conf working

reklis · 2024-09-10 14:22:44

same issue. what version of tzdata did you downgrade to?

seth · 2024-09-10 14:28:45

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?

nmars · 2024-09-10 14:34:01

hi ive downgrated to tzdata-2024a-2-x86_64.pkg.tar.zst

Last edited by nmars (2024-09-10 14:34:30)

Trilby · 2024-09-10 14:38:46

Affecting only waybar and being fixed by a downgrading only tzdata is extrodinarily unlilkely.

nmars · 2024-09-10 14:52:31

i said what i said no offense maybe unlikely but its working

seth · 2024-09-10 14:56:19

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?

elliottophellia · 2024-09-10 15:17:01

nmars wrote:

hi ive downgrated to tzdata-2024a-2-x86_64.pkg.tar.zst

lmao its actually work, thanks bro.

borrie · 2024-09-10 15:31:25

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.

Earthgame_s · 2024-09-10 16:19:07

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)

psykokura · 2024-09-10 17:36:10

Trilby wrote:

"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)

robd · 2024-09-10 18:09:49

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)

EmberQuill · 2024-09-10 19:10:28

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.

Trilby · 2024-09-10 19:53:54

nmars wrote:

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)

taflaj · 2024-09-10 22:57:26

reklis wrote:

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)

fossdd · 2024-09-11 05:35:40

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

Ref: https://gitlab.archlinux.org/archlinux/ … /issues/13

samin · 2024-09-11 05:36:32

Its working for me after the new update (tzdata 2024b-2)

psykokura · 2024-09-11 10:54:18

EmberQuill wrote:

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.

once · 2024-12-06 22:29:30

new install, b2 broke waybar date, back to a2, done.

defragmenteur · 2024-12-07 02:01:38

once wrote:

new install, b2 broke waybar date, back to a2, done.

You can force local timezone with the L prefix in format-alt

"format-alt": "{:L%Y-%m-%d %H:%M}",

More info here

Arch Linux

#1 2024-09-10 11:43:24

[SOLVED] Waybar clock showing UTC instead of local

#2 2024-09-10 12:57:47

Re: [SOLVED] Waybar clock showing UTC instead of local

#3 2024-09-10 13:03:18

Re: [SOLVED] Waybar clock showing UTC instead of local

#4 2024-09-10 14:22:44

Re: [SOLVED] Waybar clock showing UTC instead of local

#5 2024-09-10 14:28:45

Re: [SOLVED] Waybar clock showing UTC instead of local

#6 2024-09-10 14:34:01

Re: [SOLVED] Waybar clock showing UTC instead of local

#7 2024-09-10 14:38:46

Re: [SOLVED] Waybar clock showing UTC instead of local

#8 2024-09-10 14:52:31

Re: [SOLVED] Waybar clock showing UTC instead of local

#9 2024-09-10 14:56:19

Re: [SOLVED] Waybar clock showing UTC instead of local

#10 2024-09-10 15:17:01

Re: [SOLVED] Waybar clock showing UTC instead of local

#11 2024-09-10 15:31:25

Re: [SOLVED] Waybar clock showing UTC instead of local

#12 2024-09-10 16:19:07

Re: [SOLVED] Waybar clock showing UTC instead of local

#13 2024-09-10 17:36:10

Re: [SOLVED] Waybar clock showing UTC instead of local

#14 2024-09-10 18:09:49

Re: [SOLVED] Waybar clock showing UTC instead of local

#15 2024-09-10 19:10:28

Re: [SOLVED] Waybar clock showing UTC instead of local

#16 2024-09-10 19:53:54

Re: [SOLVED] Waybar clock showing UTC instead of local

#17 2024-09-10 22:57:26

Re: [SOLVED] Waybar clock showing UTC instead of local

#18 2024-09-11 05:35:40

Re: [SOLVED] Waybar clock showing UTC instead of local

#19 2024-09-11 05:36:32

Re: [SOLVED] Waybar clock showing UTC instead of local

#20 2024-09-11 10:54:18

Re: [SOLVED] Waybar clock showing UTC instead of local

#21 2024-12-06 22:29:30

Re: [SOLVED] Waybar clock showing UTC instead of local

#22 2024-12-07 02:01:38

Re: [SOLVED] Waybar clock showing UTC instead of local

Board footer