-
-
Notifications
You must be signed in to change notification settings - Fork 690
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clock module doesn't change with system timezone change #3570
Comments
happened to me too today, do you have testing repo enabled? if yes, the problem comes from "core-testing/tzdata" version 2024b-1 |
I don't have the testing repo enabled -- my version is |
I have the same problem, also no testing repo installed just the regular package. |
well tzdata-2024b-1 was just released to core. and so I have the same issue with my waybar clock and I currently have no means of downgrade. this time it defaulted to UTC for me (down from a UTC+3 region) |
there's also an error/warning when starting waybar:
|
If you need the older tzdata package well here you have ! just go to the letter T scroll all the way down and download the older package ! https://archive.archlinux.org/packages/ |
Again, the older version doesn't work. I think this is a bug with waybar's implementation. |
I also have this problem and if I try to set the
I hope for a fix :) |
strange... I don't get any timezone errors |
also downgrading my tzdata package did fix it for me |
I believe this is a C++ standard library bug -- I filed an issue for libc++, and it seems that libstdc++ fixed the bug (but just haven't shipped a version containing the fix). |
For now, should Waybar maybe switch to using the |
It was literally driving me crazy, I thought I had something wrong with my configuration. |
I just updated Waybar and am also experiencing this issue. As suggested by @eeelbrens, downgrading |
And again, that doesn't work for everyone. Furthermore, downgrading system libraries generally isn't rhe best idea. |
Yes, I’m aware. I only wanted to document that this solution worked for me too. |
Just commenting that I am also experiencing this issue as of yesterday, probably after running pacman -Syu in arch by the sounds of it. |
I've experienced this issue after one of the system updates. Downgrading tzdata to version 2024-a1 fixed the problem. |
even downgrading to 2024-a2 would fix it |
Obviously not a permanent or complete solution, but I've added this for now as a stopgap to my config: "custom/clock": {
"format": " {}",
"exec": "date +'%I:%M'",
"interval": 1
}, |
Thanks to tzdata devs, I'm 1 hour younger now. |
Just wanted to chime in - downgrading tzdata makes me old again. Thanks for your work in this! |
Updated to tzdata 2024b-2 and i am happy to say it now works as expected |
Well, the latest |
yeah I did check and update both packages and it's been fixed |
@eeelbrens I think you guys were having a different issue from me. I'm currently on Waybar 0.11, tzdata 2024b-2, and I'm STILL getting the original timezone issue. The current time is actually 3:33 PM (15:33). This is NOT about it being at UTC -- this is about it being stuck in my old timezone. |
Right now, I'm in Argentina (ART timezone) coming from Los Angeles (PDT timezone). My system clock updated automatically -- when I'm in GNOME, the time shows correctly, the
date
command shows the time correctly, as well astty-clock
,swaylock
,timedatectl
, etc. However, Waybar's clock module is still stuck in my old timezone.The text was updated successfully, but these errors were encountered: