waybar displaying wrong timezone
timedatectl outputs the following:
Local time: Sun 2024-03-17 20:16:08 EDT
Universal time: Mon 2024-03-18 00:16:08 UTC
RTC time: Mon 2024-03-18 00:16:09
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
However, after v0.10.0, waybar is now saying it is currently midnight.
Don't know if you have a timezone set in your config file, but maybe try to first set your time zone with timedatectl because it looks like your output isn't reporting any.
it is set, I just removed it for privacy, should've said that
also, it worked perfectly before the most recent update. I currently have the timezone force set in waybar as a workaround, but I don't think I should have to set the timezone.
I'd like to chime in an say that I'm also facing this issue. It was working perfectly up until the update and now it only displays UTC instead of my timezone.
Same here, clock displays UTC instead of my local timezone.
It used to work just fine in the previous version.
same, waybar-clock displays hwclock (utc by default but responds to time/date changes in uefi)
same, waybar-clock displays hwclock (utc by default but responds to time/date changes in uefi)
I didn't know that.
But I have my hwclock synced with my OS clock anyway, both are set to my local timezone but Waybar still displays UTC.
this is not correct, my hwclock is not displaying UTC and waybar still does not display the correct timezone unless manually set.
I have the opposite challenge using Waybar v.0.9.9 on Ubuntu 22.04. I only see my timezone's time when I want to see UTC.
I have tried the following timezone settings:
-
"timezone": "UTC" -
"timezone": "Universal" -
"timezone": "GMT" -
"timezone": "UCT"
Try updating to v0.10
Issue still remains with Waybar v0.10.2. Workaround is manually set the timezone in ~/.config/waybar/config:
"clock#date": {
"timezone": "America/Argentina/Buenos_Aires",
"format": "{:%A %b %d}",
"format-alt": "{:%Y-%m-%d}",
"tooltip-format": "<big>{:%Y %B}</big>\n<tt><small>{calendar}</small></tt>",
"interval": 60
},
"clock#time": {
"timezone": "America/Argentina/Buenos_Aires",
"format": "{:%H:%M:%S}",
"interval": 1
},
Issue still remains with
Waybar v0.10.2. Workaround is manually set the timezone in~/.config/waybar/config:"clock#date": { "timezone": "America/Argentina/Buenos_Aires", "format": "{:%A %b %d}", "format-alt": "{:%Y-%m-%d}", "tooltip-format": "<big>{:%Y %B}</big>\n<tt><small>{calendar}</small></tt>", "interval": 60 }, "clock#time": { "timezone": "America/Argentina/Buenos_Aires", "format": "{:%H:%M:%S}", "interval": 1 },
Yup, this should be marked as a regression IMO.
This issue still persists with 10.4-2
Even with "timezone": "Europe/Amsterdam", I still only see UTC, and not UTC+2.
On waybar 0.10.4-2 (Arch).
Looks like waybar doesn't work with sys-libs/timezone-data-2024b, at least have same issue with waybar at gentoo. Masked 2024b until fixed.
I'm currently facing the same issue:
Although I'd swear this behavior wasn't there last week and the time displayed my timezone, I'm not sure. Maybe this bug only appears when certain time conditions are met? This issue had been silent for months, but today there are three reports of it. I'll post updates if it resolves itself without any specific updates addressing the issue.
Mine is not working either, the debug log is saying : [2024-09-08 17:55:58.688] [warning] Timezone: Asia/Dhaka. std::chrono::tzdb: cannot locate zone: Asia/Dhaka
I am also facing the same problem. Waybar clock is using Universal time instead of my local time
Same issue here:
Waybar v0.10.4
i tried following configs
"timezone": "Europe/Vienna"
"timezone": "Europe/Vienna (CEST, +0200)"
and i also tried to reconfigure hwclock
no success
timedatectl Local time: Sun 2024-09-08 15:47:00 CEST Universal time: Sun 2024-09-08 13:47:00 UTC RTC time: Sun 2024-09-08 13:47:00 Time zone: Europe/Vienna (CEST, +0200) System clock synchronized: yes NTP service: active RTC in local TZ: no
i remember waybar showing the correct time some weeks ago
Looks like waybar doesn't work with sys-libs/timezone-data-2024b, at least have same issue with waybar at gentoo. Masked 2024b until fixed.
I have the same issue on Arch Linux, and I can confirm that downgrading the package tzdata from 2024b-1 to 2024a-2 fixes the problem. I suggest this as a temporary workaround for now.
Here's the changelog from 2024a to 2024b. It seems that something changed in the naming of the timezones, as in the changelog it says
System V names are now obsolescent. The main data form now uses %z.
Maybe this is useful to debug the issue?
Mine is not working either, the debug log is saying :
[2024-09-08 17:55:58.688] [warning] Timezone: Asia/Dhaka. std::chrono::tzdb: cannot locate zone: Asia/Dhaka
I don't even see any log message, not even with --log-level trace. I'm on Arch Linux.
Looks like waybar doesn't work with sys-libs/timezone-data-2024b, at least have same issue with waybar at gentoo. Masked 2024b until fixed.
Yeah, This is it. Arch homies should downgrade too, until there's some more communication on this bug. I don't know which package contains/modifies timezone data on Arch though, as it might be subsumed in a larger package. I just downgraded the package on Gentoo and restarted waybar.
Looks like waybar doesn't work with sys-libs/timezone-data-2024b, at least have same issue with waybar at gentoo. Masked 2024b until fixed.
I have the same issue on Arch Linux, and I can confirm that downgrading the package
tzdatafrom 2024b-1 to 2024a-2 fixes the problem. I suggest this as a temporary workaround for now.
Can confirm, works like a charm after the downgrade!
Looks like waybar doesn't work with sys-libs/timezone-data-2024b, at least have same issue with waybar at gentoo. Masked 2024b until fixed.
I have the same issue on Arch Linux, and I can confirm that downgrading the package
tzdatafrom 2024b-1 to 2024a-2 fixes the problem. I suggest this as a temporary workaround for now.
Same here, downgrading to 2024a-2 fixes the issue.
Same issue on arch, downgrading 2024b to 2024a-2 fixes - Arch Linux
Also confirming that on Arch tzdata is the culprit - downgrade to fix.
Same Issue here after executing "doas pacman -Syu" on Arch Linux
Also confirming that downgrading tzdata is the way to fix it on Arch
another workaround is a custom module:
"custom/clock": {
"exec": "date +\"%F %H:%M\"",
"interval": 10
},
adding on that downgrading tzdata solves the issue on arch, hope this can be looked into soon