No need for tzdata module

[jmtd]

The tzdata module reinstalls the tzdata RPM. But the tzdata RPM is not installed in the UBI10 minimal image.

[jerboaa]

The tzdata module reinstalls the tzdata RPM. But the tzdata RPM is not installed in the UBI10 minimal image.

The java-21-openjdk-headless RPM in RHEL 10 has a dependency on tzdata-java:

Requires:
[...]
tzdata-java >= 2025a

What am I missing?

[jmtd]

What am I missing?

Just that tzdata and tzdata-java are distinct RPMs.

[jerboaa]

What am I missing?

Just that tzdata and tzdata-java are distinct RPMs.

OK. So why do we do the re-install dance on other base images? I have some vague memory of tzdata being needed as well, but it escapes me why.

[jmtd]

I have some vague memory of tzdata being needed as well, but it escapes me why.

You are right to question this. I think the context was around whether Java honoured the --tz argument to Podman, which did some stuff under the hood to change the timezone. There's a reproducer of sorts in https://issues.redhat.com/browse/OPENJDK-2587

Looking at the behaviour for this image, I see the following behaviour (wallclock time is approx 10:48 UTC+1)

podman run --rm -ti --tz Europe/Berlin tzdata

no tzdata installed:

/usr/bin/date: Fri May 16 11:48:05 CEST 2025
java.time.ZonedDateTime.now(): 2025-05-16T09:48:05.516095380Z[GMT]

tzdata installed:

/usr/bin/date: Fri May 16 11:48:07 CEST 2025
java.time.ZonedDateTime.now(): 2025-05-16T11:48:07.298262883+02:00[Atlantic/Jan_Mayen]

IOW, to get the correct time we need tzdata installed in addition to tzdata-java. I'm not really sure what purpose tzdata-java serves.

And so this PR is incorrect in so far as we actually need to install (not reinstall) tzdata.

---

test files:
tzdatatest.zip

[jmtd]

I think we need a behave test to catch this.

[jerboaa]

Thanks for this.

IOW, to get the correct time we need tzdata installed in addition to tzdata-java. I'm not really sure what purpose tzdata-java serves.

My take is that tzdata is needed to support the container runtime's --tz switch. tzdata-java is needed for time zone data on the Java level (i.e. if you set the time zone in java code).

[jmtd]

Tricky to test this. Defining TZ=<desired timezone> works whether tzdata is installed or not. podman --tz only works if tzdata is installed. Under the hood, podman --tz (at least 4.9.3) copies the local system timezone definition to /etc/localtime within the running container. Current behave steps don't support either volume-mounting to that location, or copying a file over it, or passing --tz to Podman. Podman's precise behaviour may also vary with versions, I recall some bugs about losing info by /etc/localtime not being a symlink, that might have been resolved since 4.9.3, Im not sure.

[jmtd]

Ah, podman symlinks /etc/localtime to the desired TZ IF tzdata is installed/available, and copies the host's if it is not.

[jmtd]

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.