Time is behind by 4 hours
Regression?
No
Hyprlock Info and Version
v0.5.0
Hyprlock config
label {
monitor =
text = $TIME12
text_align = center
color = rgb(224, 222, 244)
font_size = 48
font_family = Cartograph CF
rotate = 0
position = 0, 120
halign = center
valign = center
}
Compositor Info and Version
System/Version info
Compositor: niri 0.1.9 (v0.1.9-56-gc8044a9)
OS: Arch Linux
Description
My local time is 2:44 PM, but hyprlock shows 10:44 AM
Occurs with both $TIME12 and $TIME
My system was first on PDT, but then I set the time to ART (+4 hours) when I first got to Argentina (where I'm currently staying)
How to reproduce
Unsure, this may be a tzdata issue? (ref: https://github.com/Alexays/Waybar/issues/3570)
Crash reports, logs, images, videos
No response
we use the C++ stdlib here with std::chrono::current_zone so I am unsure how this could be a problem with hyprlock. @PaideiaDilemma any ideas?
I can also reproduce it when setting my tz to different time zones. Fixable by either downgrading tzdata, or using gcc >= 14.3 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116657)
Since you closed the issue in waybar my guess is that waybar was compiled with a different stdlib that works with the new tzdata version and hyprlock wasn't.
It seems that GCC 14.3 isn't available on Arch Linux -- this should've already been fixed in libstdc++, but for some reason, building hyprlock from source doesn't fix the issue (even though it does for waybar) :thinking:
(and for anyone reading this affected, text = cmd[update:1000] echo "$(date +'%l:%M %p')" works as an alternative)
this should've already been fixed in libstdc++, but for some reason, building hyprlock from source doesn't fix the issue (even though it does for waybar) 🤔
I think hyprlock is build with gcc and waybar with clang? Also on archlinux the waybar PKGBUILD depends on 'libdate-tz.so', but hyprlock doesn't.
I think hyprlock is build with gcc and waybar with clang?
That'd explain it