Red Hat Bugzilla – Bug 76549
old zoneinfo data for Europe/Tallinn
Last modified: 2016-11-24 10:25:29 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 Description of problem: Early this year, the Estonian government decided to participate in Daylight Savings time. The zoneinfo that accompanies RHL7.2/glibc-common-2.2.4-30, /usr/share/zoneinfo/Europe/Tallinn, doesn't reflect this change. Version-Release number of selected component (if applicable): glibc-common-2.2.4-30 How reproducible: Always Steps to Reproduce: 1. date Actual Results: Wed Oct 23 09:52:20 EET 2002 (EET indicates Estonian Standard Time.) Expected Results: Wed Oct 23 10:52:20 EEST 2002 (EEST indicates Estonian Summer Time.) Additional info: Resolving this problem isn't urgent since we stop using Daylight time this Sunday, October 27, 2002. The zoneinfo with glibc-common-2.2.5-40 in RHL 7.3 is correct, so I assume that RHL 8.0 is correct, too.
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.