From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.7.10) Gecko/20050719 Galeon/1.3.21
Description of problem:
For some reason the section of dhclient-script below was called. It replaced "/etc/localtime" with a new copy and renamed the original to "/etc/localtime.predhclient". It caused the time zone to go from PDT to GMT-6. Instead of just setting the time 2 hours off that might be expected, the time was 11 hours off.
if [ -n "$new_time_offset" ]; then
# DHCP option "time-offset" is requested by default and should be handled.
# The geographical zone abbreviation cannot be determined from the GMT offset,
# but the $ZONEINFO/Etc/GMT$offset file can be used:
tzfile=/usr/share/zoneinfo/Etc/GMT`printf '%+d' $z`;
if [ -e $tzfile ]; then
/bin/mv -f /etc/localtime /etc/localtime.predhclient;
/bin/cp -fp $tzfile /etc/localtime;
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Haven't tried
Created attachment 118331 [details]
New localtime that broke time
Created attachment 118332 [details]
Original localtime that was renamed by the script
I don't think this should be the default, and there should definitely be an
option to turn it off.
In my case it was a cable company dhcp server that likely triggered this. I
don't agree with the idea of letting the cable company set my /etc/localtime. I
don't like /etc/resolv.conf being replaced either, but at least it is more
logically and has PEERDNS=no to disable it.
It looks like the offset of the GMT timezone files has the wrong sign. I.e. I am
in Central Time, but the GMT-6 file seems to result in a time that is 6 hours
ahead of GMT, not behind. Bug in tzdata?
Even then, this doesn't seem to take daylight saving time into account, at least
with my isp's dhcp server. Right now it reports -6, which is CST, not CDT, which
My time keeps moving forward by 11 hours as well:
$ date; TZ=EST5EDT date
Mon Sep 12 19:36:56 GMT-5 2005
Mon Sep 12 10:36:56 EDT 2005
My DHCP server is a FC3 box. This needs to be an opt-in option. It is only
useful for mobile users.
(In reply to comment #6)
> My time keeps moving forward by 11 hours as well:
I meant 9 hours, sorry. Again it looks like it's adding 5 hours instead of
subtracting, and not taking DST into account.
This bug is now fixed with dhcp-3.0.2-22.FC4 (FC4) and dhcp-3.0.3-6 (Rawhide).
I can understand why you would not want the machine time zone set on your
home computer by your cable provider .
The time-offset processing now must be enabled with a setting in an ifcfg- file
or the /etc/sysconfig/network file: DHCP_TIME_OFFSET_SETS_TIMEZONE=yes .
The rationale behind providing the time-offset support was that time-offset
is a parameter requested by dhclient by default, and was not being handled
by the dhclient-script. It could be useful for people with networks of
machines spanning multiple timezones, or with ensuring that groups of machines
get the same wall-clock time, and when setting the NTP server parameters with
DHCP. I wasn't expecting that ISVs providing DHCP service to home computers
would set this option .
The problem was that while the $zoneinfo/Etc/GMT* files are named with
positive hours east of Greenwich, they contain "seconds west of Greenwich" -
so the GMT-5 file contains 'gmtoff=18000' (GMT PLUS 5 hours), and the GMT+5
file contains 'gmtoff=-18000' (GMT MINUS 5 hours), which is highly non-intuitive
and possibly a tzdata bug - sorry for the mistake.
The server should be taking account of DST in the value it specifies for
time-offset - when told to be at a certain time-offset from GMT, the client
should not modify that value based on what DST it was at - GMT has no DST.
dhcp-3.0.2-22.FC4 will be in FC-4 updates tomorrow.
From User-Agent: XML-RPC
dhcp-3.0.2-22.FC4 has been pushed for FC4, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.