Description of problem: # hwclock Thu 11 Oct 2012 08:47:01 AM KST -0.577307 seconds # date Thu Oct 11 17:47:13 KST 2012 # cat /etc/adjtime 0.000000 1349844028 0.000000 1349844028 LOCAL # ls -al /etc/localtime lrwxrwxrwx. 1 root root 30 Sep 29 00:27 /etc/localtime -> /usr/share/zoneinfo/Asia/Seoul Version-Release number of selected component (if applicable): 9.41-2.fc18.x86_64 How reproducible: always, whenever booting Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: systemd-194-1.fc18.x86_64 glibc-2.16-17.fc18.x86_64
This should be now handled in systemd.
What's the output of: $ hwclock --test --debug ? Any other issues regarding the system time besides the weird hwclock output?
rebooting # hwclock --test --debug hwclock from util-linux 2.22.1 Using /dev interface to clock. Last drift adjustment done at 1349844028 seconds after 1969 Last calibration done at 1349844028 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/12 08:52:50 Hw clock time : 2012/10/12 08:52:50 = 1349999570 seconds since 1969 Fri 12 Oct 2012 08:52:50 AM KST -0.133971 seconds # date Fri Oct 12 17:52:58 KST 2012 # cat /etc/adjtime 0.000000 1349844028 0.000000 1349844028 LOCAL
My time from date was 9 hours ahead of date as well. After the call of #hwclock --systohc --utc they are the same, even after reboot. Could this help?
(In reply to comment #3) > # cat /etc/adjtime > LOCAL The system is configured to run the RTC in localtime not in UTC, so I guess the 9 hours offset is just the expected 9h KST offset. To run the RTC in UTC, which is in the end the only reliable and supportable setting for Linux, just delete /etc/adjtime, or put UTC in it instead of LOCAL.
I see nothing to fix here, this is simply the result of the timezone delta. Closng. (Feel free to reopen, if I missed anything here...)