Red Hat Bugzilla – Bug 321911
/etc/localtime is not updated when tzdata is updated
Last modified: 2015-05-04 21:33:33 EDT
Description of problem:
/etc/localtime is a copy of a file in /usr/share/zoneinfo/, this copy is made
when the system is installed. This file is not updated when an updating tzdata
RPM is installed - as happened recently.
Would it not be better to make this file a symbolic link, then it always reads
correctly, this is what Debian does.
Alternatively the tzdata postinstall script could use ZONE in
/etc/sysconfig/clock to copy up the latest version.
Update of /etc/localtime is taken care of by glibc trigger. How do you know
that the update has not been performed?
We can't make /etc/localtime a symlink, because /usr/ can be mounted separately,
and glibc needs to know zoneinfo even then.
I thought that that might be the reason, so why not have the postinstall script
in the updating RPM copy up the latest version ? Would that cause problems with
rpm --verify ?
tzdata package is installed very early, even before libc, and certainly before
shell. So you can't just use cp to update /etc/localtime in postinstall. You
probably could create a binary that does the same, and link it statically, but
then tzdata would lose their noarch status. That's not problem on itself, but
it makes little sense to do that just for update script.
So, why do you think that the update of /etc/localtime has not been performed?
Have you compared /etc/localtime and the file matching your zone in some way?
Or did one of the applications just fail to have synced time? If that is the
case, which one -- it may well be bug in that application (e.g. evolution and
java use their own copy of tzdata, IIRC).
This should not happen during routine update, about the only scenario that I can
imagine is update from old-ish version of RHEL-4, where the trigger has not yet
been available, and failure of rpm to run the trigger during subsequent update
I noticed new /usr/share/zoneinfo/Europe/London files coming down (eg a few days
ago), but the date on /etc/localtime is never changed. I don't know how often I
would expect it to change, but I would expect to see an update.
I have not had any application problems.
Hmm, that is strange, London has not been changed in ages... But let's see this
scenario: new tzdata arrived via latest erratum
What happens is that London zoneinfo file gets updated, because it's overwritten
from new tzdata package. But it's contents didn't chagne. Now trigger in glibc
is written in such a way that it doesn't update /etc/localtime when its zone
contents didn't change, so it skips the update, and /etc/localtime seems to be
Does it make a sense?
Ahah - so you are saying that if it had changed, the copy in /etc/localtime
would have been updated. If so - no problem.
Sorry for raising a non issue.
Glad to be of help.