Bug 783398

Summary: Error in UTC time and hardware clock
Product: [openSUSE] openSUSE 12.2 Reporter: Forgotten User 36kTZSIwRV <forgotten_36kTZSIwRV>
Component: YaST2Assignee: Jiří Suchomel <jsuchome>
Status: RESOLVED NORESPONSE QA Contact: Jiri Srain <jsrain>
Severity: Normal    
Priority: P5 - None CC: dmueller, pbaudis, werner
Version: Final   
Target Milestone: ---   
Hardware: 64bit   
OS: openSUSE 12.2   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Forgotten User 36kTZSIwRV 2012-10-03 18:15:19 UTC
User-Agent:       Opera/9.80 (X11; Linux x86_64; U; OpenSUSE 11.4; pl) Presto/2.10.289 Version/12.02

Welcome.
I have a question, and at the same time setting error in the YaST module for time management.
I have set in YaST would not save me universal time clock hardware only use local time. And after I reboot the computer time changes to UTC. I've tried various settings. Setting the time manually. But still change my OpenSUSE 12.2 on UTC. That was not in 12.1.

Reproducible: Always
Comment 1 Forgotten User cAXlJ_FoSf 2012-10-03 21:28:27 UTC
Reassign to YaST2.
Comment 2 Jiří Suchomel 2012-10-24 10:16:02 UTC
Can you attach your /etc/adjtime?
Comment 3 Dr. Werner Fink 2012-10-24 10:35:42 UTC
Please provide some more informations with the commands

   zcat /boot/initrd | cpio -i --quiet --to-stdout  etc/adjtime
   sudo hwclock --debug --show

and within a bash

   . /etc/sysconfig/clock
   echo $TIMEZONE
   TZ=UTC date
   TZ=$TIMEZONE date
   zcat /boot/initrd | cpio -i --quiet --to-stdout etc/localtime | md5sum
   md5sum /usr/share/zoneinfo/$TIMEZONE

at least let us see if warpclock had been executed in the initrd at boot

   ls /dev/shm/warpclock
Comment 4 Forgotten User 36kTZSIwRV 2012-10-24 12:46:05 UTC
zcat /boot/initrd | cpio -i --quiet --to-stdout  etc/adjtime

answer:
marcinz@lapek:~> zcat /boot/initrd | cpio -i --quiet --to-stdout  etc/adjtime
2452.640115 1349120674 0.000000
1349120674
LOCAL
marcinz@lapek:~>

sudo hwclock --debug --show

lapek:~ # hwclock --debug --show
hwclock from util-linux 2.21.2
Using /dev interface to clock.
Last drift adjustment done at 1349120674 seconds after 1969
Last calibration done at 1349120674 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: 2012/10/24 14:44:23
Hw clock time : 2012/10/24 14:44:23 = 1351082663 seconds since 1969
Wed Oct 24 14:44:23 2012  -0.532021 seconds


lapek:~ # . /etc/sysconfig/clock
lapek:~ #    echo $TIMEZONE
Europe/Warsaw
lapek:~ #    TZ=UTC date
Wed Oct 24 12:46:17 UTC 2012
lapek:~ #    TZ=$TIMEZONE date
Wed Oct 24 14:46:17 CEST 2012
lapek:~ #    zcat /boot/initrd | cpio -i --quiet --to-stdout etc/localtime | md5sum
2ed881ef7e09c844c009673ded84c798  -
lapek:~ #    md5sum /usr/share/zoneinfo/$TIMEZONE
2ed881ef7e09c844c009673ded84c798  /usr/share/zoneinfo/Europe/Warsaw


lapek:~ # ls /dev/shm/warpclock
/dev/shm/warpclock
lapek:~ #
Comment 5 Dr. Werner Fink 2012-10-24 13:06:45 UTC
(In reply to comment #4)

>   lapek:~ #    TZ=UTC date
>   Wed Oct 24 12:46:17 UTC 2012
>   lapek:~ #    TZ=$TIMEZONE date
>   Wed Oct 24 14:46:17 CEST 2012

IMHO the file /usr/share/zoneinfo/Europe/Warsaw is broken on your system or something is really bad wired.  This because enve if the system is in UTC and the user space is in UTC the last date line has to report the time in Warsaw with ``UTC'' reported by the system clock as reference.

Please show the result of

 md5sum /usr/share/zoneinfo/UTC
Comment 6 Dr. Werner Fink 2012-10-24 13:09:20 UTC
Beside this you may also attach the environment variables used on your system that is run

   printenv > my.env

and attach the file my.env
Comment 7 Dr. Werner Fink 2012-10-24 13:15:34 UTC
Add maintainer of Base:System/timezone to CC
Comment 8 Dr. Werner Fink 2012-10-25 12:35:55 UTC
Is there something new?
Comment 9 Jiří Suchomel 2013-01-04 11:38:33 UTC
Marcin, anything new? See comments 5 and 6
Comment 10 Jiří Suchomel 2013-02-13 09:20:30 UTC
no response