from https://github.com/rh-openjdk/redhat-openjdk-containers/pull/586#issuecomment-2891320695

To summarize the situation: I think OpenJDK works fine with timezones and tzdata-java installed. If you define TZ=… in the environment, java picks it up. All good.

What breaks without the full tzdata installed is podman --tz feature, and that's because it copies the host system's tzdata entry for the desired zone to /etc/localtime as a regular file. The time zone data doesn't actually include the timezone name. The only way to figure that out in normal circumstances is to read the symlink at /etc/localtime, which is not available. So any app (not just Java) would fail in this scenario: the information simply isn't available inside the container.

IFF the full tzdata is installed, then podman --tz instead sets /etc/localtime to a symlink, as normal, and the timezone name can be inferred.

From our POV then, we have to weigh up the cost of installing full tzdata (863.2 kB compressed RPM, 4.5M uncompressed on disk) in order to fix the behaviour of podman --tz. 4.5M isn't a lot (but it all adds up). I expect podman --tz is a rarely used feature for our customers, and the workaround is simple (-e TZ= instead). However, the implementation of the logic is likely in some shared component (libpod or runc or ??) that might get exposed elsewhere (OpenShift?), I will investigate.