It seems that format_time of tztime doesn't works correctly after v2.14.
If the configuration is written as follows, the string expected to be printed is "<span foreground='#ee9a00'>21-11-14 (Sun) 02:27:51</span>" but I got "%y-%m-%d (%a) %H:%M:%S".
tztime local {
format = "<span foreground='#ee9a00'>%time</span>"
format_time = "%y-%m-%d (%a) %H:%M:%S"
}
It seems that maybe_escape_markup is not used in the current implementation.
In other words, the current behavior is the same as if format_time was not used and strftime format was used in format.
I want to keep it as is and I think it is better to be fixed in the another pull request because I think it's rare that the output text is long, so I don't think it's a big problem as it is.
Problem
It seems that
format_time
oftztime
doesn't works correctly after v2.14.If the configuration is written as follows, the string expected to be printed is
"<span foreground='#ee9a00'>21-11-14 (Sun) 02:27:51</span>"
but I got"%y-%m-%d (%a) %H:%M:%S"
.The detailed behavior of
format_time
is described in the doc: https://i3wm.org/docs/i3status.html#_tztimeCause
The cause is that
format
is not correctly used.format
should be used when printing butformat_time
is used in v2.14.The source code of the previous version v2.13 uses
format
. https://github.com/i3/i3status/blame/101215bbc83b97de30b6b535bbe2e93d2e913804/src/print_time.c#L68-L77This pull request fixes it.
Workaround
You can use
%
informat
directly.Another issue
maybe_escape_markup
was used in previous versions to sanitize date-time string formatted withformat_time
,https://github.com/i3/i3status/blame/101215bbc83b97de30b6b535bbe2e93d2e913804/src/print_time.c#L74
Although, it doesn't care about the length of the buffer, I think it can lead to buffer overflow.
It seems that
maybe_escape_markup
is not used in the current implementation. In other words, the current behavior is the same as ifformat_time
was not used andstrftime
format was used informat
. I want to keep it as is and I think it is better to be fixed in the another pull request because I think it's rare that the output text is long, so I don't think it's a big problem as it is.