haproxy icon indicating copy to clipboard operation
haproxy copied to clipboard

"ltime" converter does not reflect container timezone

Open yolabingo opened this issue 1 year ago • 4 comments

ltime reports the server timezone as UTC regardless of what is set as the TZ environment variable in the container.

Adding the tzdata package to the image appears to resolve this issue.

yolabingo avatar Sep 13 '23 21:09 yolabingo

Does HAProxy intentionally support the TZ environment variable in this way, or is this more incidental? The shared link just says "local time" with no indication of how "local time" is determined (which is often via /etc/localtime).

tianon avatar Dec 11 '23 21:12 tianon

HA Proxy needs to be able to get timezone data from the OS, which is provided by the tzdata package in Debian and Alpine.

Setting the TZ environment variable is a POSIX-compliant way to set the system timezone, and it is commonly used when running containers. See https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html

Creating /etc/localtime as a symlink to a zoneinfo file is another way to set the system timezone

lrwxrwxrwx 1 root root 36 Dec 12 00:18 /etc/localtime -> /usr/share/zoneinfo/America/New_York

but this obviously still requires the tzdata package which provides the files in /usr/share/zoneinfo

yolabingo avatar Dec 12 '23 05:12 yolabingo

Right, sorry, let me be more specific -- is this an intentional feature of HAProxy, or an incidental one? How common of a use case is it to use "local time" within HAProxy?

My references to /etc/localtime were not suggesting it should be a symlink to other files within the container (which as you've noted, would require tzdata), but rather bind-mounted from the host where "local time" typically means something more than it does inside containers and thus wouldn't need to be a symlink at all (and wouldn't need to add the extra unremovable package of tzdata which most users likely aren't going to do much with).

In general, we avoid adding things to images we maintain which are not in common or explicit upstream recommended usage especially because it's easy for end users to install, but if we pre-install it, it's very difficult for them to remove (due to the nature of container image layering).

tianon avatar Dec 12 '23 19:12 tianon

I would say this is intentional. I do understand the need to keep containers as simple as possible. In my opinion, an image should include all OS packages required to run the core service, so this HAProxy docker image is broken without the tzdata package.

The HA Proxy feature ltime seems to require tzdata to function. https://docs.haproxy.org/dev/configuration.html#7.3.1-ltime

[ltime] converts an integer supposed to contain a date 
since epoch to a string representing this date in local time

Without tzdata installed, HAProxy ltime returns incorrect values. HAProxy does not issue warnings about missing zoneinfo files. It is not at all obvious to users of this image why ltime is broken. I don't know if other HAProxy features require tzdata.

I think the best solution is to add tzdata. Perhaps a reasonable alternative would be to document that this image does not support ltime and why.

yolabingo avatar Dec 12 '23 22:12 yolabingo