It looks like no fix is coming in time for our upcoming change to Daylight time
(in a week and a half), so I have a question about fixing this manually:

I copied /usr/share/zoneinfo/Europe/Tallinn from a 7.3 system to the same
location on my 7.2 system.  I also ran timeconfig to update /etc/localtime.  Is
there any process I need to stop and start to recognize the change in
/etc/localtime?

Any process which uses the time info would have to be restarted.

I assume the problem is solved is recent releases?  Can you confirm this?

I discovered that at least crond had to be restarted.  I rebooted my 7.2 systems
to make sure I restarted all of the processes that use the time.

Estonian (Tallinn) time is correct in Red Hat Linux 7.3 and 8.0.  I haven't had
time to examine RHL9 and I don't have access to any Enterprise versions.  A
quick way to check is to see if /usr/share/zoneinfo/Europe/Tallinn is 814 bytes,
the correct size.  The out-of-date file is smaller.

If new updates for glibc-common are released, please include the correct Tallinn
file.  But it's fine with me if you don't issue any more glibc-common updates
before the end of the RHL7.2 maintenance period.

Sorry, just re-read your question again and saw that you were probably asking
about the latest glibc-common release:  The latest release of glibc-common for
RHL7.2, 2.2.4-32 in March 2003, didn't have the new Tallinn file.  I didn't
actually test it, but the file size was the same as before.

It's not 7.2 I'm concerned about.  If you need up-to-date data you need to use
recent releases.  Old releases get security updates.

So, if you have the problem with RHL9 let me know.  Then I'll give you
instructions how to submit the data to the upstream maintainer.  If it is fixed
in RHL9 you can copy the data from that release to your old installation.

This bug was specifically filed against RHL 7.2, so I'll close it with a
resolution of WONTFIX.  But I expected all supported releases to receive the
correct timezone data whenever an update to glibc-common was issued.

As far as I know, the upstream data at elsie.nci.nih.gov is still okay.  I have
extracted the Europe/Tallinn file for RHL 9 and its size and sum match the file
for RHL8.0 - it is correct.  I leave it to someone else to verify the data in
the RHEL releases.

I can see the problem of reacting to every zoneinfo change and making everyone
reboot their computer every 6 months.  But at the same time, it is bad to get an
incorrect zoneinfo file every time glibc-common gets updated.  Fortunately,
/etc/localtime doesn't get changed with the RPM update.

Perhaps an RPM script could examine /etc/sysconfig/clock and check if the
designated zoneinfo file is changing (or compare it with /etc/localtime before
and after the update).  If so it could display a warning statement like,
     "Your timezone has been affected by this update, you should run
          dateconfig  from a graphical desktop
       or
          timeconfig  from a console or character terminal
     and restart your computer before the next change between Daylight Savings
(Summer) and Standard time."

I can see that I am looking at this from a command-line rpm perspective; I don't
know how you would accomplish this using up2date.