Waybar clock module broken with latest tzdata

[icp1994]

Is this a new report?

Yes

System Info

Void 6.12.10_1 x86_64 GenuineIntel uptodate ...

Package(s) Affected

Waybar-0.11.0_2 tzdata-2025a_1

Does a report exist for this bug with the project's home (upstream) and/or another distro?

Alexays/Waybar#3891

Expected behaviour

The clock module should show timezone the specified tz in config.

Actual behaviour

It shows time in UTC

Steps to reproduce

Launch Waybar along it's default config with system clock set to a non-UTC tz.

[rationalize-zz]

Did some testing, don't think its a Waybar issue directly. When calling c++ std::chrono function current_zone(), always returns UTC (nothrow behavior). When specifying a time zone, call locate_zone(), which throws exception with message around "tzdb: cannot locate zone:". Maybe our build of libstdc++ or gcc is the issue?

[EnumuratedDev]

Having the same issue with the new tzdata update as well. Downgrading to 2024a_2 seems to fix the issue. From what I could see only Waybar seemed to be affected by this. Running the date command in a terminal showed the correct time and SDDM was showing the correct time as well

[eoli3n]

Same here

[juipeltje]

yeah same issue here, just came back to void linux after using nixos for 6 months, so unfortunately i can't downgrade the package to fix it. from what i gather in other topics a gcc update solves the issue, but i'm not sure how long that would take in the case of void...

[lady-melinoe]

Currently using gcc14, compiling waybar on my system it still has the same issue? (first time in bar is date '+%I:%M %p')

[rationalize-zz]

Fixed via update to gcc's libstdc++:

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0ca8d56f2085715f27ee536c6c344bc47af49cdd

Format change in tzdb wasn't implemented in the c++ std lib. This is why updating tzdata works just fine for everything written in C (like 'date' command), or at the very least doesn't access tzdb via c++ std::chrono library.

For an extra bit of fun here, this commit didn't make it into gcc 14.2. Distros that don't have this issue have it fixed via 14.2.1, which doesn't seem to be an tagged release, not at least as far as I can find.

[jwakely]

Distros that don't have this issue have it fixed via 14.2.1, which doesn't seem to be an tagged release, not at least as far as I can find.

By definition, 14.2.1 means "some snapshot between the 14.2.0 and 14.3.0 releases" so it will never be a tagged release. Releases always end in .0 (since GCC 5.1.0).

[rationalize-zz]

Understood. I've submitted PR #54061, which backports https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0ca8d56f2085715f27ee536c6c344bc47af49cdd to gcc 13.2

[eoli3n]

This is not fix, I still get UTC in waybar-clock after the upgrade

➜ xbps-query -l | grep gcc
ii gcc-13.2.0_3  

---

edit: no i don't, i just didn't reload waybar properly