Clock Formatting For %OI

[bisby]

Expected Behavior: The clock module links to https://howardhinnant.github.io/date/date.html#to_stream_formatting - This says

%I The hour (12-hour clock) as a decimal number. If the result is a single digit, it is prefixed with 0. The modified command %OI produces the locale's alternative representation.

Previously %0I returned 8 for 8pm, whereas %I returns 08. So I would expect to have this display 8:45pm

Actual Behavior: The clock module returns nothing. Empty space on the bar. I can still see the module underline. When I click on the module it shows the full time. When I click on the module again it doesn't clear the full time, but full time stops updating.

Relevant Config:

    "clock": {
        "format": "{:%0I:%M %p}",

Relevant Log lines:

[2022-03-08 20:38:07.854] [error] clock: invalid format

This works when the %0I is changed to %I , but then the formatting isn't quite what I want. I only consider this an issue though because the linked documentation for date formatting says this should be valid.

edit: quick follow once I saw the quote text formatting... it should be %OI not %0I ... 0 worked in the past, and O works but still displays the 0 prefix (08) so is technically still not working.

[LukashonakV]

At least the issue comes from the date utility and the clock module displays info which is provided by the date library.

1. According the documentation:

The hour (12-hour clock) as a decimal number. If the result is a single digit, it is prefixed with 0. The modified command %OI produces the locale's alternative representation.

I don't see any mentions about the library should cut the leading zeros. I see it depends on you LC_TIME environment variable.

2. Try to do the same in terminal: a. date +%0I b. date +%OI c. date +%I Result on my machine:

So at least I would suggest you to check you local configuration to make sure in terminal local date utility shows the output you've expecting.

[bisby]

Interesting. It had previously worked so in my brain I registered the locale's alternative as meaning "no leading 0" (since my locale didn't change)

It seems the easiest way with date to remove the 0 is date +%-I but that isnt valid in the library waybar uses.

I also don't have any locales set up that LC_TIME will produce a non leading zero.

Seems to be an issue for me and not waybar. Though I would love to have the option to force no-prefix

[jayache80]

Is it agreed that this is indeed a bug? And, is there a known workaround?

My waybar-clock config broke recently because I use %-I that will yield single-digit hours without a leading zero. However I now must use %I which yields an undesirable leading zero, else I have an invalid waybar-clock config.

If the intent of the date library that waybar-clock uses is to mimic the functionality of the date command, I'd say it's not currently doing that, because:

date +%-I

works just fine to provide a single digit hour without leading zero (and %-I used to work just fine in waybar-clock until recently).

[LukashonakV]

@bisby, @jayache80 Not sure I understand correct. Please take a look at my screenshot:

1. Please look at the top waybar which I ran for an example with the changed time.
2. Please take a look a the config is opened on the left window. For me it looks like working correct

[bisby]

For me i get in my logs [error] clock: invalid format and the clock shows up as an empty space. This works fine when the only change is %I but then i have the leading zeroes.

When running with waybar -l trace I get:

[2022-04-11 17:22:44.982] [warning] As using a timezone, some format args may be missing as the date library haven't got a release since 2018.

But nothing else clock related.

[LukashonakV]

Lets summarize:

1. You are using waybar ver. 0.9.12 ?
2. Can you check waybar config, maybe by the mistake you filled clock block, especially "format" parameter twice or more times ?

At my screenshot I repeated format and format-alt sections like in your example.

[jayache80]

1. You are using waybar ver. 0.9.12 ?

I tried both 0.9.12 and waybar-git-r1906.503fe9a-1 (arch linux AUR package), and have the same result.

2. Can you check waybar config, maybe by the mistake you filled clock block, especially "format" parameter twice or more times ?

Having this clock block in my waybar config:

    "clock": {
        // "timezone": "America/New_York",
        "tooltip-format": "<big>{:%Y %B}</big>\n<tt><small>{calendar}</small></tt>",
        "format": "{:%I}"
    },

will work to show a leading 0 hour only.

Having this in the clock block of my waybar config:

    "clock": {
        // "timezone": "America/New_York",
        "tooltip-format": "<big>{:%Y %B}</big>\n<tt><small>{calendar}</small></tt>",
        "format": "{:%-I}"

will break, and then I get nothing in the clock area.

As @bisby has alluded, is this perhaps caused by a timezone locale configuration, a system date library thing, or some other system config thing?

Using the clock block's timezone field yielded even stranger results.

This clock block:

    "clock": {
        "timezone": "America/New_York",
        "tooltip-format": "<big>{:%Y %B}</big>\n<tt><small>{calendar}</small></tt>",
        "format": "{:%I}"
    },

yields a leading 0 hour (in NY time, a different timezone than mine. Neat.)

This clock block:

    "clock": {
        "timezone": "America/New_York",
        "tooltip-format": "<big>{:%Y %B}</big>\n<tt><small>{calendar}</small></tt>",
        "format": "{:%-I}"
    },

strangely yields a literal %-I in the clock area.

[LukashonakV]

As @bisby has alluded, is this perhaps caused by a timezone locale configuration, a system date library thing, or some other system config thing?

I'm using GNU coreutils with the fmt package version - 8.32-r1. Can you check is the same version is installed on your machine or you're using another one or even another fmt package. Actually according the code this fmt package handles text formatting.

[bisby]

fmt (GNU coreutils) 9.0

[jayache80]

fmt 8.1.1-2 is what I was using to produce the above mentioned behavior.

I installed fmt-git 8.1.1.r180.g86e27ccb-1 and tried to build waybar-git-r636.67593b8-1 but I got in library hell and couldn't build:

/usr/include/fmt/core.h:1725:7: error: static assertion failed: Cannot format an argument. To make type T formattable provide a formatter<T> specialization: https://fmt.dev/latest/api.html#udt
 1725 |       formattable,
      |       ^~~~~~~~~~~
/usr/include/fmt/core.h:1725:7: note: ‘formattable’ evaluates to false

[jayache80]

I made a request to fmtlib: https://github.com/fmtlib/fmt/issues/2959

Either some strftime features are no longer fully implemented in fmt (as %-I used to work on Waybar and now it doesn't, but Waybar has always used fmt from what I gather) or the usage is now different and there's now user error.

[hajosattila]

OFF LukashonakV please share your waybar css and config file! (very nice)

[LukashonakV]

Hi @hajosattila , config is Dotfiles

[LukashonakV]

Hi @bisby is this still actual ?

[bisby]

I've been back on i3wm so not using waybar recently. but booting it up to check...

[2023-01-27 15:28:12.955] [error] clock: invalid format

for

"clock": {
    "format": "{:%-I:%M %p}",

So yes. clock formatting with no leading zeroes is seemingly still not possible in my locale. And I'm now on fmt (GNU coreutils) 9.1

[iambumblehead]

I want my waybar to look like gnome's date time area --no leading '0' on the month number

[jayache80]

Upstream fmt has brought in a commit to master (but not in any releases yet) that should resolve this issue:

https://github.com/fmtlib/fmt/commit/7718eeeacc98c2dfb6fe8714fb38ef31f2921ab9

I had trouble building waybar with latest fmt (problems with spdlog) so I couldn't test yet.

Also, these are related and possibly the same underlying issue: https://github.com/Alexays/Waybar/issues/1696 https://github.com/Alexays/Waybar/issues/1447

[LukashonakV]

Hi @jayache80 , @bisby, @iambumblehead according upstream this feature was implemented by the PR#3271 . I've checked the source code and looks like once fmt will be official release Waybar can use this feature. For example see: test/chrono-test.cc

[kohsine]

Stumbled onto this issue while googling how to remove leading zero. Is this still an issue a year later?