Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
First Last Prev Next    This bug is not in your last search results.
Bug 137733 - inappropriate timezone change
inappropriate timezone change
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency tree / graph
 
Reported: 2004-10-31 13:31 EST by Tarhon-Onu Victor
Modified: 2007-11-30 17:10 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-30 11:24:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

  None (edit)
Description Tarhon-Onu Victor 2004-10-31 13:31:33 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).
Comment 1 Jakub Jelinek 2004-11-01 03:42:45 EST 
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.
Comment 2 Harald Hoyer 2004-11-01 04:28:23 EST 
advice: use ntpd and not ntpdate.
Comment 3 Tarhon-Onu Victor 2004-11-01 05:04:54 EST 
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.
Comment 4 Ulrich Drepper 2005-06-30 15:41:19 EDT 
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.
Comment 5 Tim Waugh 2005-07-01 06:30:47 EDT 
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.
Comment 6 Matthew Miller 2006-07-10 17:00:13 EDT 
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!
Comment 7 John Thacker 2006-10-30 11:24:25 EST 
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.
Note You need to log in before you can comment on or make changes to this bug.
First Last Prev Next    This bug is not in your last search results.