This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 469081 - GMT-1 shows up as GMT+1 and vice versa
GMT-1 shows up as GMT+1 and vice versa
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: tzdata (Show other bugs)
5.2
i386 Linux
medium Severity high
: rc
: ---
Assigned To: Petr Machata
qe-baseos-daemons
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-29 15:33 EDT by Kit Gerrits
Modified: 2015-05-04 21:34 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-08-11 08:44:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kit Gerrits 2008-10-29 15:33:39 EDT
Description of problem:
If I set /etc/localtime to GMT+1, I get GMT+1 time as a result.
Likewise, if I set /etc/localtime to /etc/GMT-1 I get GMT+1 as a result.
Things get even stranger is I try to check my time against hwclock (VM inside VMWare ESX)
After a reboot, the machine comes back with the wrong system time (exactly 1 hour off)

Version-Release number of selected component (if applicable):
tzdata-2008e-1.el5

How reproducible:
set timezoene to Etc/GMT+1

Steps to Reproduce:
1. date
2. cp /usr/share/zoneinfo/Etc/GMT+1 /etc/localtime
3. date
  
Actual results:
time 1 hour before GMT

Expected results:
time 1 hour past GMT

Additional info:
UTC functions correctly:
## pre-change check:
# date
Wed Oct 29 19:02:30 UTC 2008
# date -u
Wed Oct 29 19:02:32 UTC 2008
# hwclock.dist --show
Wed 29 Oct 2008 07:02:36 PM UTC  -0.593267 seconds
# hwclock.dist --show --utc
Wed 29 Oct 2008 07:02:38 PM UTC  -0.069620 seconds

## change:
# cp /usr/share/zoneinfo/Etc/GMT-1 /etc/localtime

## post-change result:
# date
Wed Oct 29 20:06:15 GMT-1 2008
# date -u
Wed Oct 29 19:06:16 UTC 2008
# hwclock.dist --show
Wed 29 Oct 2008 07:06:39 PM GMT-1  -0.212912 seconds
# hwclock.dist --show --utc
Wed 29 Oct 2008 08:06:42 PM GMT-1  -0.532984 seconds

## EXPECTED result:
# (please pay attention to reported times)
# date
Wed Oct 29 20:06:15 GMT+1 2008
# date -u
Wed Oct 29 19:06:16 UTC 2008
# hwclock.dist --show
Wed 29 Oct 2008 08:06:39 PM GMT+1  -0.212912 seconds
# hwclock.dist --show --utc
Wed 29 Oct 2008 07:06:42 PM GMT+1  -0.532984 seconds


## Temporary fix:
1/ mv /sbin/hwclock /sbin/hwclock.dist
2/ set timezone to UTC
3/ ntpdate
4/ set timezone to GMT-1
5/ install hourly 'ntpdate' cron-job (Virtual Machine, no ntpd available)
6/ (optional) reboot)
Comment 1 Petr Machata 2008-10-29 16:30:38 EDT
Does what's written at #224442 answer your report?
Comment 2 Kit Gerrits 2008-10-29 18:26:23 EDT
It explains the origin of the 'discrepancy', but not why hwclock goes haywire when queried/used or why the clock get 'offset' by one hour after a reboot.
Somewhere, hwclock reads/writes local and reads/writes UTC at another point during a reboot.
Please have a close look at what hwclock reports:


# date; date -u; hwclock --show; hwclock --show --utc
Wed Oct 29 23:00:59 GMT-1 2008
Wed Oct 29 22:00:59 UTC 2008
Wed 29 Oct 2008 11:00:59 PM GMT-1  -0.043202 seconds
Thu 30 Oct 2008 12:01:00 AM GMT-1  -0.985860 seconds

# ls -l /etc/localtime
lrwxrwxrwx 1 root root 29 Oct 21 10:02 /etc/localtime -> /usr/share/zoneinfo/Etc/GMT-1

# cat /etc/sysconfig/clock
ZONE="GMT+1"
UTC=false
ARC=false
; Yes, I know timezone GMT+1 does not exist, should be /etc/GMT+1

# rpm -qa |grep -i vmware
xorg-x11-drv-vmware-10.13.0-2.1
VMwareTools-7302-110268

# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.2 (Tikanga)
Comment 3 Karel Zak 2008-10-30 05:31:40 EDT
Please, try

  # hwclock --show --debug

and

 # cat /etc/adjtime

It seems that your hwclock(8) assumes "LOCAL" time instead "UTC".
Comment 4 Kit Gerrits 2008-10-30 13:48:12 EDT
# date; date -u; hwclock --show; hwclock --show --utc; hwclock --show --debug; hwclock --show --debug --utc

Thu Oct 30 18:47:04 GMT-1 2008

Thu Oct 30 17:47:04 UTC 2008

Thu 30 Oct 2008 05:46:57 PM GMT-1  -0.119765 seconds

Thu 30 Oct 2008 06:46:58 PM GMT-1  -0.987247 seconds

hwclock from util-linux-2.13-pre7
Using /dev/rtc interface to clock.
Last drift adjustment done at 1225300755 seconds after 1969
Last calibration done at 1225300755 seconds after 1969
Hardware clock is on local time
Assuming hardware clock is kept in local time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2008/10/30 17:46:59
Hw clock time : 2008/10/30 17:46:59 = 1225385219 seconds since 1969
Thu 30 Oct 2008 05:46:59 PM GMT-1  -0.988708 seconds

hwclock from util-linux-2.13-pre7
Using /dev/rtc interface to clock.
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2008/10/30 17:47:00
Hw clock time : 2008/10/30 17:47:00 = 1225388820 seconds since 1969
Thu 30 Oct 2008 06:47:00 PM GMT-1  -0.990013 seconds

# cat /etc/adjtime
-61.181191 1225300755 0.000000
1225300755
LOCAL


My thoughts exactly
Comment 5 Kit Gerrits 2011-04-13 10:06:02 EDT
Apparently, the +/- behavious is not a bug, but a POSIX standard:
http://regebro.wordpress.com/2007/12/18/python-and-time-zones-fighting-the-beast/
http://labs.hoffmanlabs.com/node/120

Apparently, GMT itself is a rather long story:
http://www.mail-archive.com/leapsecs@rom.usno.navy.mil/msg00109.html

Note You need to log in before you can comment on or make changes to this bug.