Red Hat Bugzilla – Bug 137733
inappropriate timezone change
Last modified: 2007-11-30 17:10:53 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040131 Description of problem: I don't know if this happens because of glibc, tzdata or something else, I suppose it's glibc. My timezone is EEST during summer and EET during the rest of the year, so I'll use this as example. Premises: 1. If the system time is changed after 2004-10-31 03:00:00 then the timezone is changed from EEST to EET; 2. Usually 2004-10-31 04:00:00 EEST becomes 2004-10-31 03:00:00 EET; 3. there is a ntp daemon running or you run (say, hourly) ntpdate your.favorite.ntp.server.here from cron. So, if the ntp daemon or the ntpdate program changes the system time after 03:00:00.000 the timezone change also occurs, and it shouldn't. If there is nothing running that can change the system time then the timezome remains EEST (in my case) even after 03:00. Version-Release number of selected component (if applicable): 2.3.3-63 How reproducible: Always Steps to Reproduce: 1. on a test system type, as root: date 103102592004; 2. Wait until 03:00. You will notice that the timezone remains EEST (or your summer time) even after 03:00; 3.set the date again to: 103103002004. The system time will have the timezone set to EET. Actual Results: Any system time change after 0300 means also timezone change. If the time is not changed then the timezone is changed at 0400. If the system time os not changed then 03:59:59 EEST becames 03:00:00 EET, as expected. Expected Results: I expect that the timezone is changed no matter what at 04:00 but not anytime between 03:00 and 04:00, and not to be dependent of the time changes after 03:00. I suppose this happens because all folks set the system time at 03:00 and not after, but what happens when te system time is changed automatically and/or periodically? The system time will be the same with the same time zone and a lot of thing will be screwed up (databases recording timestamps with timezone, by example). Additional info: This happened both on servers having in /etc/sysconfig/clock the following: == cut here == UTC=true ARC=false ZONE="Europe/Bucharest" == and here == or not having /etc/sysconfig/clock at all (I installed them by hand with rpm -Uhv -r /path/to/mountpoint/ and not using RH/FC installer).
If you do date 103103002004, then the time being in EET timezone is expected. The time specification you pass to date does not include is_dst information and as there are two different times when time is 2004-10-31 03:00 (EEST and EET), the system just picks the latter. But I always thought ntp exchanged dates in timezone neutral format.
advice: use ntpd and not ntpdate.
This happened both on hosts running ntpdate from cron or running ntpd. I think (but I may be wrong) the problem is neither the ntp server, the ntp client or date comand from the GNU core utilities. They set the system time using settimeofday() using as the second argument a NULL value. A possible fix for this can be: the timezone has to be set to the current timezone instead of EET for time changes between 03:00 and 03:59:59.999. If the timezone was allready changed than it's ok, if not, it's ok too.
This has nothing to do with glibc. If anything is wrong at all, it might be users of glibc functions like settimeofday. Assigning to coreutils since it contains the date command.
According to the man page, there is never a reason to give a non-zero second argument to settimeofday(): The tz argument is a timezone : struct timezone { int tz_minuteswest; /* minutes W of Greenwich */ int tz_dsttime; /* type of dst correction */ }; The use of the timezone struct is obsolete; the tz_dsttime field has never been used under Linux - it has not been and will not be supported by libc or glibc. Each and every occurrence of this field in the ker- nel source (other than the declaration) is a bug. Thus, the following is purely of historic interest.
Fedora Core 3 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC5 updates or in the FC6 test release, reopen and change the version to match. Thank you!
Closing per lack of response to previous request for information. This bug was originally filed against a much earlier version of Fedora Core, and significant changes have taken place since the last version for which this bug is confirmed. Note that FC3 and FC4 are supported by Fedora Legacy for security fixes only. Please install a still supported version and retest. If it still occurs on FC5 or FC6, please reopen and assign to the correct version. Otherwise, if this a security issue, please change the product to Fedora Legacy. Thanks, and we are sorry that we did not get to this bug earlier.