Due to an influx of spam, we have had to temporarily disable account registrations. Please write an email to accountsupport@archlinux.org, with your desired username, if you want to get access. Sorry for the inconvenience.
There's been some possibly relevant upstream changes in the latest release. If it mainly only affects waybar, this could easily be an issue that upstream waybar devs need to fix.
FWIW, I just tried building with some patches from https://github.com/eggert/tz and still get the same problem..
I believe this is a C++ standard library bug (waybar comment) -- libc++ doesn't support %z at this time, and libstdc++ doesn't contain the fix in its latest release.
I filed a bug report with llvm-project to fix libc++, but I do worry that more projects than just waybar may be affected.
is there an upstream bug report for libstdc++? Since this regression affects basically all C++ programs that use time zones, a timely release of a libstdc++ fix would be important.
If there is no timely fix release from libstdc++, could Arch ship that fix commit as a patch to libstdc++ in its gcc-libs package?
Hey, thanks for that! I ripped your reproducer and filed an equivalent GCC issue. cc @freswa
If this proves to be an overall hassle, the "vibe" from upstream tzdata appears to be "stay on 2024a" which for us would involve epoch downgrade, bleh..
Java seems to have been affected by a different issue in this same version of tzdata ("April" instead of "Apr"):
The java timezone updater fails with the following error message:
Caused by: java.lang.IllegalArgumentException: Unknown month: April
at
tools.tzdb.TzdbZoneRulesProvider$MonthDayTime.parseMonth(TzdbZoneRulesProvider.java:391)