Everywhere in system date is correct, but waybar shows UTC time

[Zilibobka-S]

[PARTIALLY SOLVED!] Waybar clock: ⟩ waybar -l trace [2024-09-07 19:16:59.856] [debug] Try expanding: $XDG_CONFIG_HOME/waybar/config [2024-09-07 19:16:59.856] [debug] Try expanding: $XDG_CONFIG_HOME/waybar/config.jsonc [2024-09-07 19:16:59.856] [debug] Try expanding: $HOME/.config/waybar/config [2024-09-07 19:16:59.856] [debug] Try expanding: $HOME/.config/waybar/config.jsonc [2024-09-07 19:16:59.856] [debug] Found config file: $HOME/.config/waybar/config.jsonc [2024-09-07 19:16:59.856] [info] Using configuration file /home/zilibobka/.config/waybar/config.jsonc [2024-09-07 19:16:59.858] [info] Discovered appearance 'dark' [2024-09-07 19:16:59.858] [debug] Try expanding: $XDG_CONFIG_HOME/waybar/style-dark.css [2024-09-07 19:16:59.858] [debug] Try expanding: $XDG_CONFIG_HOME/waybar/style.css [2024-09-07 19:16:59.858] [debug] Try expanding: $HOME/.config/waybar/style-dark.css [2024-09-07 19:16:59.858] [debug] Try expanding: $HOME/.config/waybar/style.css [2024-09-07 19:16:59.858] [debug] Found config file: $HOME/.config/waybar/style.css [2024-09-07 19:16:59.858] [info] Using CSS file /home/zilibobka/.config/waybar/style.css [2024-09-07 19:16:59.863] [debug] Output detection done: HDMI-A-1 (Philips Consumer Electronics Company PHL 222V8 ZV02102004927) [2024-09-07 19:16:59.864] [warning] Mapping is not an object [2024-09-07 19:16:59.867] [warning] Timezone: Europe/Moscow. std::chrono::tzdb: cannot locate zone: Europe/Moscow [2024-09-07 19:16:59.881] [debug] GTK widget tree: window#waybar.background.bottom.HDMI-A-1..mode-default:dir(ltr) decoration:dir(ltr) box.horizontal:dir(ltr) box.horizontal.modules-left:dir(ltr) widget:dir(ltr) box#workspaces.horizontal.module:dir(ltr) widget:dir(ltr) label#custom-right-arrow-dark.module:dir(ltr) box.horizontal.modules-center:dir(ltr) widget:dir(ltr) label#custom-left-arrow-dark.module:dir(ltr) widget:dir(ltr) label#clock.1.module:dir(ltr) widget:dir(ltr) label#custom-left-arrow-light.module:dir(ltr) widget:dir(ltr) label#custom-left-arrow-dark.module:dir(ltr) widget:dir(ltr) label#clock.2.module:dir(ltr) widget:dir(ltr) label#custom-right-arrow-dark.module:dir(ltr) widget:dir(ltr) label#custom-right-arrow-light.module:dir(ltr) widget:dir(ltr) label#clock.3.module:dir(ltr) widget:dir(ltr) label#custom-right-arrow-dark.module:dir(ltr) box.horizontal.modules-right:dir(ltr) widget:dir(ltr) label#custom-left-arrow-dark.module:dir(ltr) widget:dir(ltr) label#pulseaudio.module:dir(ltr) widget:dir(ltr) label#custom-left-arrow-light.module:dir(ltr) widget:dir(ltr) label#custom-left-arrow-dark.module:dir(ltr) widget:dir(ltr) label#memory.module:dir(ltr) widget:dir(ltr) label#custom-left-arrow-light.module:dir(ltr) widget:dir(ltr) label#custom-left-arrow-dark.module:dir(ltr) widget:dir(ltr) label#cpu.module:dir(ltr) widget:dir(ltr) label#custom-left-arrow-light.module:dir(ltr) widget:dir(ltr) label#custom-left-arrow-dark.module:dir(ltr) widget:dir(ltr) label#disk.module:dir(ltr)

[2024-09-07 19:16:59.882] [warning] Timezone: Europe/Moscow. std::chrono::tzdb: cannot locate zone: Europe/Moscow [2024-09-07 19:16:59.882] [warning] Timezone: Europe/Moscow. std::chrono::tzdb: cannot locate zone: Europe/Moscow [2024-09-07 19:16:59.882] [warning] Timezone: Europe/Moscow. std::chrono::tzdb: cannot locate zone: Europe/Moscow [2024-09-07 19:16:59.985] [info] Bar configured (width: 1920, height: 26) for output: HDMI-A-1 [2024-09-07 19:17:00.000] [warning] Timezone: Europe/Moscow. std::chrono::tzdb: cannot locate zone: Europe/Moscow [2024-09-07 19:17:00.000] [warning] Timezone: Europe/Moscow. std::chrono::tzdb: cannot locate zone: Europe/Moscow [2024-09-07 19:17:00.000] [warning] Timezone: Europe/Moscow. std::chrono::tzdb: cannot locate zone: Europe/Moscow [2024-09-07 19:17:01.000] [warning] Timezone: Europe/Moscow. std::chrono::tzdb: cannot locate zone: Europe/Moscow [2024-09-07 19:17:02.000] [warning] Timezone: Europe/Moscow. std::chrono::tzdb: cannot locate zone: Europe/Moscow [2024-09-07 19:17:03.000] [warning] Timezone: Europe/Moscow. std::chrono::tzdb: cannot locate zone: Europe/Moscow [2024-09-07 19:17:04.000] [warning] Timezone: Europe/Moscow. std::chrono::tzdb: cannot locate zone: Europe/Moscow [2024-09-07 19:17:05.000] [warning] Timezone: Europe/Moscow. std::chrono::tzdb: cannot locate zone: Europe/Moscow ^C[2024-09-07 19:17:05.722] [info] Quitting.

Timedatectl output: Local time: Sat 2024-09-07 19:18:02 MSK Universal time: Sat 2024-09-07 16:18:02 UTC RTC time: Sat 2024-09-07 16:18:02 Time zone: Europe/Moscow (MSK, +0300) System clock synchronized: yes NTP service: active RTC in local TZ: no

Waybar config:

config.jsonc

you can downgrade tzdata package, it helps

[ignamartinoli]

Exactly same problem with America/Argentina/Cordoba

[barksjn]

Same: America/Indiana/Indianapolis

If it helps I use arch testing repositories and tzdata has an update from the 6th. If I revert the update the waybar clock works right.

[pkreuzt]

See:

https://github.com/Alexays/Waybar/wiki/Module:-Clock#troubleshooting

If using clock instead of simpleclock, the locale will default to C regardless of the locale settings. To override this behavior you have to perpend L to the formatting string. For example, {:%a %m %d} becomes {:L%a %m %d}.

[Zilibobka-S]

I downgraded tzdata package, it helps, but its still weird

[Maulve]

Can confirm with Europe/Berlin. Downgrading tzdata fixed it though.

[Syyhis]

While using tzdata 2024b-1, std::chrono time zone database seems to be incorrect. Iterating over std::chrono::tzdb_list and printing out all the zone names per std::chrono::tzdb gives only Etc/GMT and Etc/UTC. Tested this out with a small program. Downgrading to tzdata 2024a-2 indeed seems to fix this issue.

[TheKoTech]

See:

https://github.com/Alexays/Waybar/wiki/Module:-Clock#troubleshooting

If using clock instead of simpleclock, the locale will default to C regardless of the locale settings. To override this behavior you have to perpend L to the formatting string. For example, {:%a %m %d} becomes {:L%a %m %d}.

Putting "L" in front doesn't work, nor using simpleclock

[akgupta1337]

Having same issue! downgrade to 2024a works https://archive.archlinux.org/packages/t/tzdata/

[YuvanMichaelVivenzi]

me too!

[YuvanMichaelVivenzi]

I downgraded tzdata and it works fine now

[distantstatic]

I also believe it is something to do with the tzdata package.

If using Arch and Pacman: Do note the online archive is not the only location for a rollback version.

Check /var/cache/pacman/pkg/ for the old tzdata and install using pacman -U https://wiki.archlinux.org/title/Downgrading_packages

[lfos]

While using tzdata 2024b-1, std::chrono time zone database seems to be incorrect. Iterating over std::chrono::tzdb_list and printing out all the zone names per std::chrono::tzdb gives only Etc/GMT and Etc/UTC. Tested this out with a small program. Downgrading to tzdata 2024a-2 indeed seems to fix this issue.

Thanks for the analysis; I think this should be reported upstream (to tzdata). There seem to be others reporting issues with tzdata 2024b-1 that may or may not be related (https://lists.iana.org/hyperkitty/list/[email protected]/thread/6PF5BB7342JR6PALTMQFEGU2FZ5ADW36/). @Syyhis Reporting your findings on the tzdata mailing list may increase awareness and help get out a new release faster.

Too bad this wasn't noticed and analyzed before the package left [core-testing], otherwise it'd have been easy to pull the Arch package, but I guess it's now easiest to just locally downgrade and hold the package until a new release is out.

[itshog]

Could this be a duplicate of #3024?

[lfos]

Could this be a duplicate of #3024?

I looks like the original issue described in #3024 is different, but that thread was revived recently discussing the same issue as reported here. So - no, this is not a duplicate, but the second half of the discussion in #3024 should instead have gone into a new bug / here.

[itshog]

Could this be a duplicate of #3024?

I looks like the original issue described in #3024 is different, but that thread was revived recently discussing the same issue as reported here. So - no, this is not a duplicate, but the second half of the discussion in #3024 should instead have gone into a new bug / here.

Thanks for the clarification, I believed this was the case but I wasn't sure about it

[NuclearC]

Downgrade to tzdata 2024-a2 fixes the problem.

[UntitledHam]

I am having this same issue

[chardoncs]

+1

Update: Okay, I just briefly looked through the source code. It looks not likely a waybar bug. Waybar just gets the datetime through std library. That's probably why rolling back tzdata fixes the issue. (idk I might be wrong...)

[AMIRIOX]

same issue

$ downgrade tzdata # choose 2024a-2

restart waybar
done

[christiansacks]

Thanks for the info about downgrading tzdata 👍 I can confirm that worked for me in Arch also;

$ ls -lhrt /var/cache/pacman/pkg/tzdata-*
-rw-r--r-- 1 root root  310 Feb  2  2024 /var/cache/pacman/pkg/tzdata-2024a-1-x86_64.pkg.tar.zst.sig
-rw-r--r-- 1 root root 387K Feb  2  2024 /var/cache/pacman/pkg/tzdata-2024a-1-x86_64.pkg.tar.zst
-rw-r--r-- 1 root root  310 May  1 19:43 /var/cache/pacman/pkg/tzdata-2024a-2-x86_64.pkg.tar.zst.sig
-rw-r--r-- 1 root root 350K May  1 19:43 /var/cache/pacman/pkg/tzdata-2024a-2-x86_64.pkg.tar.zst
-rw-r--r-- 1 root root  310 Sep  6 15:08 /var/cache/pacman/pkg/tzdata-2024b-1-x86_64.pkg.tar.zst.sig
-rw-r--r-- 1 root root 347K Sep  6 15:08 /var/cache/pacman/pkg/tzdata-2024b-1-x86_64.pkg.tar.zst

I installed the 2nd to latest (same ver as mentioned above - 2024a-2)

$  sudo pacman -U /var/cache/pacman/pkg/tzdata-2024a-2-x86_64.pkg.tar.zst

Then restarted waybar and clock displays the correct time again.

NOTE: Don't forget to add tzdata to your IgnorePkg= line in /etc/pacman.conf or it'll upgrade again when you next do that 😅

[dR3b]

Nice, but downgrade is not a solution.

[TheKoTech]

Update: Okay, I just briefly looked through the source code. It looks not likely a waybar bug.

If waybar breaks, but not any other program, then it's waybar. On my system, that's the case

[christiansacks]

Nice, but downgrade is not a solution.

Perhaps not, but it's a solid workaround until tzdata is fixed or Waybar can create a solution to work around it for us?

[rudrakshchahal]

I dont have tzdata a-2 to downgrade what should I do

[cluosh]

I dont have tzdata a-2 to downgrade what should I do

You can fetch it from the Arch archive: https://archive.archlinux.org/packages/t/tzdata/tzdata-2024a-2-x86_64.pkg.tar.zst

[thyeun]

Why it only happen on waybar (clock module)? swaylock working fine too.

[steveWang]

While using tzdata 2024b-1, std::chrono time zone database seems to be incorrect. Iterating over std::chrono::tzdb_list and printing out all the zone names per std::chrono::tzdb gives only Etc/GMT and Etc/UTC. Tested this out with a small program. Downgrading to tzdata 2024a-2 indeed seems to fix this issue.

+1

Update: Okay, I just briefly looked through the source code. It looks not likely a waybar bug. Waybar just gets the datetime through std library. That's probably why rolling back tzdata fixes the issue. (idk I might be wrong...)

Signal-boosting https://github.com/Alexays/Waybar/issues/3570#issuecomment-2336837532 -- this is a result of some new syntax in the tzdata.zi file that the main C++ standard library implementations don't yet support (fixed but not released in libstdc++ that comes with gcc, and not yet fixed in libc++ that comes with llvm / clang).

There's now a bug for this on the tzdata issue tracker, where I've mentioned that other packages might be affected.

Why it only happen on waybar (clock module)? swaylock working fine too.

Swaylock is written in C, and does not use the C++ standard library.

[thyeun]

@steveWang No wonder hyrlock affected too, since it is based on cpp library.

So any news from tzdata will fix ASAP?

[littleblack111]

the date command doesnt seem affected

[jonathansilber]

Having the same issue. Downgrading tzdata fixed it. For everyone who also never downgraded a package before (Arch) I recommend using the downgrade script from the AUR which makes downgrading pretty easy