Current tzfile(5) format does not carry time zone name. The time zone name is the long name used to point to /usr/share/zoneinfo (e.g. Europe/Prague). It's not the abbreviation (e.g. CET) which changes for each observation and which is not unique. If /etc/localtime is not a symbolic link and tzdata gets updated, so the /etc/localtime does not match any updated file under /usr/share/zoneinfo, there is no way how to determine time zone name. This causes some software difficulties. See bug #1135981 (and its reverse dependencies), request for mock workaround (bug #1136040), localtime(5) manual page, DateTime-TimeZone external bug <https://rt.cpan.org/Public/Bug/Display.html?id=55029>. Saving time zone name into compiled tzfile would allow to retrieve the name from /etc/localtime even if it's normal file (a copy, not a symbolic link).
There's a number of zones that are hardlinks to one shared zonefile, so this is impossible given the current upstream architecture. Note that recently there has been an attempt upstream to change the format to be more easily extensible, to include a meta-data block, but these changes were reverted for compatibility reasons. One doesn't simply walk^Wchange zoneinfo format. Specifically on Fedora, just look for ZONE= in /etc/sysconfig/clock. Also note that on Fedora, /etc/localtime is automatically updated after tzdata update, so the two shouldn't really get out of sync.
(In reply to Petr Machata from comment #1) > There's a number of zones that are hardlinks to one shared zonefile, so this > is impossible given the current upstream architecture. It could be a list. > Note that recently > there has been an attempt upstream to change the format to be more easily > extensible, to include a meta-data block, but these changes were reverted > for compatibility reasons. One doesn't simply walk^Wchange zoneinfo format. > That's sad. > Specifically on Fedora, just look for ZONE= in /etc/sysconfig/clock. Also > note that on Fedora, /etc/localtime is automatically updated after tzdata > update, so the two shouldn't really get out of sync. They get out of sync right now in the koji mock enviroment. See bug #1135981 and bug #1136040. What solution would you recommend? What package updates the /etc/localtime? Is it glibc's trigger on tzdata? Does the update happen even on first tzdata installation? Does the update replace existing /etc/localtime by the symlink?
(In reply to Petr Pisar from comment #2) > (In reply to Petr Machata from comment #1) > > There's a number of zones that are hardlinks to one shared zonefile, so this > > is impossible given the current upstream architecture. > > It could be a list. > > > Note that recently > > there has been an attempt upstream to change the format to be more easily > > extensible, to include a meta-data block, but these changes were reverted > > for compatibility reasons. One doesn't simply walk^Wchange zoneinfo format. > > > That's sad. Yeah, compatibility concerns are rarely glorious. > > Specifically on Fedora, just look for ZONE= in /etc/sysconfig/clock. Also > > note that on Fedora, /etc/localtime is automatically updated after tzdata > > update, so the two shouldn't really get out of sync. > > They get out of sync right now in the koji mock enviroment. See bug #1135981 > and bug #1136040. What solution would you recommend? How did this happen? There's a trigger on glibc package that should update /etc/localtime when tzdata gets updated. Why didn't it run? > Does the update replace existing /etc/localtime by the symlink? Last time I checked, the trigger just copied over a new version. But we may have changed to symlinks in the mean time, the rationale for using a copy have been moot since Fedora's UsrMove. So, why don't you look into /etc/sysconfig/clock? That's what the trigger does.
(In reply to Petr Machata from comment #3) > (In reply to Petr Pisar from comment #2) > > (In reply to Petr Machata from comment #1) > > > Specifically on Fedora, just look for ZONE= in /etc/sysconfig/clock. Also > > > note that on Fedora, /etc/localtime is automatically updated after tzdata > > > update, so the two shouldn't really get out of sync. > > > > They get out of sync right now in the koji mock enviroment. See bug #1135981 > > and bug #1136040. What solution would you recommend? > > How did this happen? There's a trigger on glibc package that should update > /etc/localtime when tzdata gets updated. Why didn't it run? > Have you read the referred bugs? It's written there. It happens when installing system into mock chroot by mock tool. That means even koji build system is affected. And maybe there is another problem: The tzdata is not updated. The tzdata is installed. Does the trigger cover this scenario too? > > Does the update replace existing /etc/localtime by the symlink? > > Last time I checked, the trigger just copied over a new version. But we may > have changed to symlinks in the mean time, the rationale for using a copy > have been moot since Fedora's UsrMove. > > So, why don't you look into /etc/sysconfig/clock? That's what the trigger > does. Are you sure /etc/sysconfig/clock is still in use? I cannot see that in any of my systems. Neither timedatectl(1), nor localtime(5), nor systemd-timedated.service(8) does not mention this configuration file. So your recommendation is that mock tool should populate /etc/sysconfig/clock file before installing @build group?
(In reply to Petr Pisar from comment #4) > > How did this happen? There's a trigger on glibc package that should update > > /etc/localtime when tzdata gets updated. Why didn't it run? > > > Have you read the referred bugs? It's written there. It happens when > installing system into mock chroot by mock tool. That means even koji build > system is affected. Koji build system arguably has no need to know a TZID. > And maybe there is another problem: The tzdata is not updated. The tzdata is > installed. Does the trigger cover this scenario too? I see that much has changed since I was around. The tzdata updating logic and ownership of /etc/localtime was moved to systemd since bug 858735. /etc/sysconfig/clock is not used anymore, as you pointed out in the text that I snipped out. It also seems to have become a symbolic link. So let's recap. The problem is due to systemd not being installed in a build root, _and_ mock copying the contents instead of symlink. But there's no other way to do it, otherwise mock would create a dangling symlink that would potentially remain dangling if the in-mock tzdata doesn't have the zone the host system has. Hmm. Outside mock you shouldn't see this problem, as tzdata never drops zones (that sacred cow of compatibility again). It's really only mock that exposes this. Is it really necessary that a package knows what exact zone it's built in? Íf yes, could you possibly pretend that /etc/localtime is a legitimate zone name?
> Is it really necessary that a package knows what exact zone it's built in? Íf yes, could you possibly pretend that /etc/localtime is a legitimate zone name? The package uses a time zone name to select proper time zone defintion (as upstream insists that only the name is the proper identifier). I've already hacked the package to break this assumption. Thanks for the explanation. Therefore it's a mock (or a systemd) issue. I will forward this output back to mock bug #1136040.