Alpine ruby image fails Ruby TZ tests due to lack of tzdata

[NathanZook]

sudo docker run --env TZ=America/Los_Angeles -it ruby:slim /usr/local/bin/ruby -e 'puts Time.utc(2007, 11, 4, 9, 0, 0).localtime'

2007-11-04 01:00:00 -0800

sudo docker run --env TZ=America/Los_Angeles -it ruby:alpine /usr/local/bin/ruby -e 'puts Time.utc(2007, 11, 4, 9, 0, 0).localtime'

2007-11-04 09:00:00 +0000

Some searching led to this:
#218

Pointing to this:
https://serverfault.com/questions/683605/docker-container-time-timezone-will-not-reflect-changes/683651#683651

Pointing to this:
gliderlabs/docker-alpine#136

Which looks a LOT like this is a known issue/WONTFIX, but I must protest. This fails the ruby TZ tests.

I understand that as a minimalist distribution, Alpine, tzdata is not required, but it is required for properly-functioning ruby. If the maintainers believe that it is correct to leave tzdata out of the ruby:alpine image, then surely it is friendly to document the absence of the package, probably via a comment next to one of the apk add statements. (I would prefer it in the build set, as it is needed for the tests to pass.)

[LaurentGoderre]

Being a minimal image, it is somewhat unrealistic to document ever instance of an extra package that might be needed.

[tianon]

The current image description (https://hub.docker.com/_/ruby) includes this admittedly boilerplate blurb about the alpine variants:

To minimize image size, it's uncommon for additional related tools (such as git or bash) to be included in Alpine-based images. Using this image as a base, add the things you need in your own Dockerfile (see the alpine image description for examples of how to install packages if you are unfamiliar).

We do work hard to make sure this extends to "optional" packages also -- yes, there is core Ruby functionality that doesn't work properly without tzdata installed, but if we include it by default, users who don't need that functionality can't remove it. For tzdata, that's probably not a huge deal (since the impact will be low), but that determinization is less obvious for other things so we try to keep the policy as tight as we can (see #493 for a concrete example of that happening in practice).

I do wish it were normal for tools to error out if TZ is set to a value they don't know/can't parse instead of silently interpreting it as UTC instead, but we don't get to live in a perfect world. 😅

Another interesting "angle" to this is that Alpine (and musl in general) is not likely a well-supported target for Ruby upstream in general (in many ecosystems, this is referred to as "platform support tiers", and Alpine/musl is usually in the lowest tier if it even makes the list), so more "breakage" than just this is definitely not unexpected when using the Alpine variant, which is why it's not (and likely won't ever be) the default variant.

[NathanZook]

Being a minimal image, it is somewhat unrealistic to document ever instance of an extra package that might be needed.

I don't believe that this is an "every package" situation. Ruby has a lot (6 million?) of tests. A few more than 100 failed, and >90 are due to the lack of TZData. (I suspect that the rest of my fails were specific to running in a container, either for being root or for expected directories not existing already.)

It is very common for things to be shipped with some sort of Errata/Known Issues page. What I'm asking for is that this case be clearly documented.