waybar displaying wrong timezone

[Kommynct]

timedatectl outputs the following:

               Local time: Sun 2024-03-17 20:16:08 EDT
           Universal time: Mon 2024-03-18 00:16:08 UTC
                 RTC time: Mon 2024-03-18 00:16:09

System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

However, after v0.10.0, waybar is now saying it is currently midnight.

[ordy]

Don't know if you have a timezone set in your config file, but maybe try to first set your time zone with timedatectl because it looks like your output isn't reporting any.

[Kommynct]

it is set, I just removed it for privacy, should've said that

also, it worked perfectly before the most recent update. I currently have the timezone force set in waybar as a workaround, but I don't think I should have to set the timezone.

[ndcontini]

I'd like to chime in an say that I'm also facing this issue. It was working perfectly up until the update and now it only displays UTC instead of my timezone.

[itaranto]

Same here, clock displays UTC instead of my local timezone.

It used to work just fine in the previous version.

[vdpbl]

same, waybar-clock displays hwclock (utc by default but responds to time/date changes in uefi)

[itaranto]

same, waybar-clock displays hwclock (utc by default but responds to time/date changes in uefi)

I didn't know that.

But I have my hwclock synced with my OS clock anyway, both are set to my local timezone but Waybar still displays UTC.

[Kommynct]

this is not correct, my hwclock is not displaying UTC and waybar still does not display the correct timezone unless manually set.

[jsaern]

I have the opposite challenge using Waybar v.0.9.9 on Ubuntu 22.04. I only see my timezone's time when I want to see UTC.

I have tried the following timezone settings:

1. "timezone": "UTC"
2. "timezone": "Universal"
3. "timezone": "GMT"
4. "timezone": "UCT"

[Kommynct]

Try updating to v0.10

[Pablo1107]

Issue still remains with Waybar v0.10.2. Workaround is manually set the timezone in ~/.config/waybar/config:

    "clock#date": {
        "timezone": "America/Argentina/Buenos_Aires",
        "format": "{:%A %b %d}",
        "format-alt": "{:%Y-%m-%d}",
        "tooltip-format": "<big>{:%Y %B}</big>\n<tt><small>{calendar}</small></tt>",
        "interval": 60
    },
    "clock#time": {
        "timezone": "America/Argentina/Buenos_Aires",
        "format": "{:%H:%M:%S}",
        "interval": 1
    },

[itaranto]

Issue still remains with Waybar v0.10.2. Workaround is manually set the timezone in ~/.config/waybar/config:

    "clock#date": {
        "timezone": "America/Argentina/Buenos_Aires",
        "format": "{:%A %b %d}",
        "format-alt": "{:%Y-%m-%d}",
        "tooltip-format": "<big>{:%Y %B}</big>\n<tt><small>{calendar}</small></tt>",
        "interval": 60
    },
    "clock#time": {
        "timezone": "America/Argentina/Buenos_Aires",
        "format": "{:%H:%M:%S}",
        "interval": 1
    },

Yup, this should be marked as a regression IMO.

[malmerri42]

This issue still persists with 10.4-2

[Blazing-Blast]

Even with "timezone": "Europe/Amsterdam", I still only see UTC, and not UTC+2. On waybar 0.10.4-2 (Arch).

[alxchk]

Looks like waybar doesn't work with sys-libs/timezone-data-2024b, at least have same issue with waybar at gentoo. Masked 2024b until fixed.

[samuelcordero]

I'm currently facing the same issue:

Although I'd swear this behavior wasn't there last week and the time displayed my timezone, I'm not sure. Maybe this bug only appears when certain time conditions are met? This issue had been silent for months, but today there are three reports of it. I'll post updates if it resolves itself without any specific updates addressing the issue.

[adnanzareef]

Mine is not working either, the debug log is saying : [2024-09-08 17:55:58.688] [warning] Timezone: Asia/Dhaka. std::chrono::tzdb: cannot locate zone: Asia/Dhaka

[SimeonVutov]

I am also facing the same problem. Waybar clock is using Universal time instead of my local time

[Fennix900]

Same issue here:

Waybar v0.10.4

i tried following configs "timezone": "Europe/Vienna" "timezone": "Europe/Vienna (CEST, +0200)"

and i also tried to reconfigure hwclock

no success

timedatectl Local time: Sun 2024-09-08 15:47:00 CEST Universal time: Sun 2024-09-08 13:47:00 UTC RTC time: Sun 2024-09-08 13:47:00 Time zone: Europe/Vienna (CEST, +0200) System clock synchronized: yes NTP service: active RTC in local TZ: no

i remember waybar showing the correct time some weeks ago

[itshog]

Looks like waybar doesn't work with sys-libs/timezone-data-2024b, at least have same issue with waybar at gentoo. Masked 2024b until fixed.

I have the same issue on Arch Linux, and I can confirm that downgrading the package tzdata from 2024b-1 to 2024a-2 fixes the problem. I suggest this as a temporary workaround for now.

[itshog]

Here's the changelog from 2024a to 2024b. It seems that something changed in the naming of the timezones, as in the changelog it says

System V names are now obsolescent. The main data form now uses %z.

Maybe this is useful to debug the issue?

[itaranto]

Mine is not working either, the debug log is saying : [2024-09-08 17:55:58.688] [warning] Timezone: Asia/Dhaka. std::chrono::tzdb: cannot locate zone: Asia/Dhaka

I don't even see any log message, not even with --log-level trace. I'm on Arch Linux.

[Nick82285]

Looks like waybar doesn't work with sys-libs/timezone-data-2024b, at least have same issue with waybar at gentoo. Masked 2024b until fixed.

Yeah, This is it. Arch homies should downgrade too, until there's some more communication on this bug. I don't know which package contains/modifies timezone data on Arch though, as it might be subsumed in a larger package. I just downgraded the package on Gentoo and restarted waybar.

[alexlnkp]

Looks like waybar doesn't work with sys-libs/timezone-data-2024b, at least have same issue with waybar at gentoo. Masked 2024b until fixed.

I have the same issue on Arch Linux, and I can confirm that downgrading the package tzdata from 2024b-1 to 2024a-2 fixes the problem. I suggest this as a temporary workaround for now.

Can confirm, works like a charm after the downgrade!

[themarcman314]

Looks like waybar doesn't work with sys-libs/timezone-data-2024b, at least have same issue with waybar at gentoo. Masked 2024b until fixed.

I have the same issue on Arch Linux, and I can confirm that downgrading the package tzdata from 2024b-1 to 2024a-2 fixes the problem. I suggest this as a temporary workaround for now.

Same here, downgrading to 2024a-2 fixes the issue.

[ronasimi]

Same issue on arch, downgrading 2024b to 2024a-2 fixes - Arch Linux

[grimwaldr]

Also confirming that on Arch tzdata is the culprit - downgrade to fix.

[Spoljarevic]

Same Issue here after executing "doas pacman -Syu" on Arch Linux

[Nikola13377]

Also confirming that downgrading tzdata is the way to fix it on Arch

[hariseldon78]

another workaround is a custom module:

"custom/clock": {
          "exec": "date +\"%F %H:%M\"",
          "interval": 10
},

[7sev7nsev7n7]

adding on that downgrading tzdata solves the issue on arch, hope this can be looked into soon

[Linuxadmn4718]

Seeing the same issue this morning. RTC is set to UTC and clock is only displaying UTC.

❯ timedatectl
               Local time: Mon 2024-09-09 13:33:07 PST
               Universal time: Mon 2024-09-09 05:33:07 UTC
               RTC time: Mon 2024-09-09 05:33:07
               Time zone: Asia/Manila (PST, +0800)
System clock synchronized: yes
              NTP service: active
              RTC in local TZ: no

Can confirm downgrading tzdata resolves issue.

[user354015]

Also here to confirm, downgrading tzdata works.

[Kurumi0007]

hello, same here. After downgrading, it works correctly

[enabwds]

I was facing the same issue. It seems that the only way to fix it is to downgrade tzdata. I use arch btw.

[itaranto]

I don't think downgrading a package is a good idea. But anyway, we aren't discussing Arch Linux here.

In my case I've been having this issue for several months, are we sure this is just tzdata?

Also, I have another machine running Fedora 40 and I experience the same issue, the tzdata version here is 2024a.

[enabwds]

I'm not entirely sure about Fedora as i have no experience with it or it's derivatives. In my case the only fix that worked was to downgrade tzdata from 2024b-1 to 2024a-2. I have no clue about why you would be having the issue for several months as i had only experienced the issue after updating a few hours ago.

[furadnik]

@itaranto You might have a different issue then? I'm also running Arch, downgraded tzdata, and it's working. Also it stopped working at the same time I upgraded tzdata to 2024b-1.

[itaranto]

@itaranto You might have a different issue then? I'm also running Arch, downgraded tzdata, and it's working. Also it stopped working at the same time I upgraded tzdata to 2024b-1.

Yes, it's most likely a different issue.

I'm having this issue since version v0.10, just like the OP.

[charlesneimog]

same for me. I am on waybar 0.10.4.

[DevZiaus]

I am also having the same issue on arch. I am on waybar 0.10.4 My config:

"clock": {
        "timezone": "Asia/Dhaka",
        "format": "{:%I:%M%p}",
        "tooltip-format": "<big>{:%Y %B}</big>\n<tt><small>{calendar}</small></tt>",
        // START CLOCK FORMAT
        "format-alt": "{:%Y-%m-%d}"
    },

[Nj0be]

Same issue on arch linux, downgrading tzdata fixes it.

[Erennedirlo]

Here to confirm downgrading tzdata to 2024a-2 fixes it

[J0nnyMak0]

In other words time is stuck at GMT. It would be nice if "timzone" supported a plus-minus syntax. So "timezone": -5 would be equivalent to "America/Chicago" etc.

[Mahrjose]

Wait so it's because of the update!! I spent 2 hours trying to fix it. I was going mad :)

[nomisreual]

Looks like waybar doesn't work with sys-libs/timezone-data-2024b, at least have same issue with waybar at gentoo. Masked 2024b until fixed.

Can confirm downgrading tzdata resolved the issue for now.

[jeffreymonjacastro]

Downgrading tzdata resolved the bug for me also.

I installed downgrade with yay yay -S downgrade. Then I run sudo downgrade tzdata, and I selected 2024a-2. After that I restart it with pkill waybar & waybar &.

Hope this bug will be fixed

[beeender]

https://github.com/chronotope/chrono-tz/releases/tag/v0.10.0

It seems chrono-tz v0.10.0 fixed this.

   39       ╎ try {                                                                                                                                         
   40       ╎   tzList_.push_back(locate_zone(zone_name.asString()));                                                                                       
   41       ╎ } catch (const std::exception& e) {                                                                                                           
   42       ╎   spdlog::warn("Timezone: {0}. {1}", zone_name.asString(), e.what());                                                                         
   43       ╎ } 

(gdb) p e.what()
$4 = 0x555555a79dd8 "std::chrono::tzdb: cannot locate zone: Asia/Shanghai"

[alexlnkp]

https://github.com/chronotope/chrono-tz/releases/tag/v0.10.0

It seems chrono-tz v0.10.0 fixed this.

   39       ╎ try {                                                                                                                                         
   40       ╎   tzList_.push_back(locate_zone(zone_name.asString()));                                                                                       
   41       ╎ } catch (const std::exception& e) {                                                                                                           
   42       ╎   spdlog::warn("Timezone: {0}. {1}", zone_name.asString(), e.what());                                                                         
   43       ╎ } 

(gdb) p e.what()
$4 = 0x555555a79dd8 "std::chrono::tzdb: cannot locate zone: Asia/Shanghai"

The issue is fixed just by having 'chrono-tz' pkg? Even if that's the case, there still is a regression from a previous version, which should be reported ideally. Did anyone do that yet?

[michael555444]

Same issue Arch Linux: 6.10.9-arch1-1 waybar: 0.10.4-2 tzdata: 2024b-1 waybar config:

        "clock":    {
            "interval":             1,
            "timezone":             "Europe/Moscow",    // Without manual tz set and with
            "tooltip-format":           "<tt><small>{calendar}</small></tt>",
            "format":               "{:%H:%M:%S}",
            "format-alt":               "{:%e %B %Y (%A) [%Y.%m.%d]}",
            "calendar": {
                "mode":             "month",
                "mode-mon-col":         3,
                "on-scroll":            1,
                "format":   {
                    "months":       "<span color='#ffead3'><b>{}</b></span>",
                    "days":         "<span color='#ffffff'>{}</span>",
                    "weekdays":     "<span color='#ffcc66'><b>{}</b></span>",
                    "today":        "<span color='#ff6699'><b><u>{}</u></b></span>"
                }
            },
            "actions":  {
                "on-click-right":       "mode",
                "on-scroll-up":         "shift_up",
                "on-scroll-down":       "shift_down",
            },
            "on-click-middle":          "gnome-calendar"
        },

[aayan-infosec]

Downgrading tzdata resolved the bug for me also.

I installed downgrade with yay yay -S downgrade. Then I run sudo downgrade tzdata, and I selected 2024a-2. After that I restart it with pkill waybar & waybar &.

Hope this bug will be fixed

Downgrading did help in my case. Thank you! But, is the bug related to tzdata 2024b or waybar?