hwclock bug #74

[Paul Fox]

can we close this bug?

i believe that the current busybox hwclock applet is behaving
correctly, and, indeed, it matches the behavior of any
/sbin/hwclock i've found.

i think the only issue to be resolved with hwclock, if any, is
whether it should be trying to open /etc/adjtime (traditional) or
/var/lib/hwclock/adjtime (current behavior).

in the following tests, i've symlinked /var/lib/hwclock/adjtime
to /etc/adjtime so avoid that issue.

here's a system configured with the RTC in localtime.  the
current true wallclock time in boston is just before noon.  we're
observing DST.

    $ sh -x hwclock.test
    + ls -l /etc/adjtime /var/lib/hwclock/adjtime
    -rw-r--r--    1 root     root           46 May 25  2004 /etc/adjtime
    lrwxrwxrwx    1 root     root           12 Sep 27 11:45 /var/lib/hwclock/adjtime -> /etc/adjtime
    + cat /etc/adjtime
    0.001660 1085533366 0.000000
    1085533366
    LOCAL
    + /sbin/hwclock --localtime
    Tue Sep 27 11:57:41 2005  -0.586810 seconds
    + ./busybox hwclock --localtime
    Tue Sep 27 11:57:41 2005  0.000000 seconds
    + /sbin/hwclock --utc
    Tue Sep 27 07:57:42 2005  -0.996542 seconds
    + ./busybox hwclock --utc
    Tue Sep 27 07:57:42 2005  0.000000 seconds
    + /sbin/hwclock --show
    Tue Sep 27 11:57:43 2005  -0.996583 seconds
    + ./busybox hwclock --show
    Tue Sep 27 11:57:43 2005  0.000000 seconds
    + date
    Tue Sep 27 11:57:42 EDT 2005
    + date --utc
    Tue Sep 27 15:57:42 UTC 2005


here's a system configured with the RTC in UTC:

    $ sh -x hwclock.test 
    + ls -l /etc/adjtime /var/lib/hwclock/adjtime
    -rw-r--r--    1 root     root           47 Aug 31 22:43 /etc/adjtime
    lrwxrwxrwx    1 root     root           12 Sep 27 11:38 /var/lib/hwclock/adjtime -> /etc/adjtime
    + cat /etc/adjtime
    2064.137695 1125542623 0.000000
    1125542623
    UTC
    + /sbin/hwclock --localtime
    Tue Sep 27 15:59:09 2005  0.168862 seconds
    + ./busybox hwclock --localtime
    Tue Sep 27 15:59:09 2005  0.000000 seconds
    + /sbin/hwclock --utc
    Tue Sep 27 11:59:10 2005  0.995451 seconds
    + ./busybox hwclock --utc
    Tue Sep 27 11:59:10 2005  0.000000 seconds
    + /sbin/hwclock --show
    Tue Sep 27 11:59:11 2005  0.995654 seconds
    + ./busybox hwclock --show
    Tue Sep 27 11:59:11 2005  0.000000 seconds
    + date
    Tue Sep 27 11:59:11 EDT 2005
    + date --utc
    Tue Sep 27 15:59:11 UTC 2005


i think the crux of the confusion is that the "-l" ("--localtime") option
to hwclock does _not_ tell it how to display the time.  it tells it
whether the realtime clock is programmed in UTC or not.  if you RTC
is programmed in localtime, and you use "--utc", or if it's programmed
in UTC, and you use "--localtime", you're lying, and will get incorrect
time results.  you can see those erroneous results, above -- when
you give hwclock options that agree with the RTC, they you get good
results.  when you lie, you get bad results.

furthermore, if your RTC is programmed for localtime, and your system
doesn't reboot after DST takes effect, then there will be a one-hour
discrepancy between the values shown by "hwclock --localtime" and "date".

paul
=---------------------
 paul fox, pgf at brightstareng.com