[BusyBox 0000074]: hwclock arguments -u and -l inverted
bugs at busybox.net
bugs at busybox.net
Sat Sep 24 18:43:48 UTC 2005
A NOTE has been added to this issue.
======================================================================
http://busybox.net/bugs/view.php?id=74
======================================================================
Reported By: ralphs
Assigned To: BusyBox
======================================================================
Project: BusyBox
Issue ID: 74
Category: Standards Compliance
Reproducibility: always
Severity: minor
Priority: normal
Status: feedback
======================================================================
Date Submitted: 02-01-2005 11:35 PST
Last Modified: 09-24-2005 11:43 PDT
======================================================================
Summary: hwclock arguments -u and -l inverted
Description:
Given a system with RTC that has the time programmed in UTC, and /etc/TZ
contains EST5EDT... then the following work as expected
# date
Tue Feb 1 14:23:29 EST 2005
# date -u
Tue Feb 1 19:23:30 UTC 2005
The hwclock utility seems to mix up the two cases:
# hwclock
Tue Feb 1 19:22:17 2005 0.000000 seconds
# hwclock -u
Tue Feb 1 14:22:29 2005 0.000000 seconds
# hwclock -l
Tue Feb 1 19:22:44 2005 0.000000 seconds
Normally "hwclock" with no argument prints local time, and with "-u"
should print UTC. The "-l" option fails to print local time. Also "-l"
does not exist in the regular hwclock program.
======================================================================
----------------------------------------------------------------------
ralphs - 02-01-05 12:33
----------------------------------------------------------------------
Seems to be platform dependant as well. The above report was on PPC
target; doing the same on an x86 host behaves a little differently- the
localtime output is correct, but the UTC times are reported with 2x the
time zone applied, eg instead of UTC-5 it prints out UTC-10.
----------------------------------------------------------------------
vapier - 04-15-05 21:47
----------------------------------------------------------------------
instead of looking at `date`, look at the behavior compared to the normal
`hwclock`:
$ ./busybox hwclock -u ; hwclock -u
Fri Apr 15 19:48:55 2005 0.000000 seconds
Fri Apr 15 19:48:56 2005 -0.997188 seconds
$ ./busybox hwclock -l ; hwclock --localtime
Fri Apr 15 23:49:09 2005 0.000000 seconds
Fri Apr 15 23:49:10 2005 -0.840237 seconds
in other words, behavior looks fine to me ?
----------------------------------------------------------------------
pgf - 07-16-05 15:19
----------------------------------------------------------------------
The only bug that i see is that with no arguments, the busybox hwclock
applet returns a different value than the system hwclock command (on
systems using
UTC in the RTC).
the busybox applet tries to open and parse /var/lib/hwclock/adjtime --
why
does it assume this file exists? if the file doesn't exist, it assumes
UTC
is not in use in the rtc.
----------------------------------------------------------------------
landley - 09-01-05 04:06
----------------------------------------------------------------------
First of all, I just tried this with current cvs, and it worked ok for me.
(The display format differs quite a lot between gnu hwclock and busybox
hwclock, but the data being presented doesn't.)
$ hwclock
.Thu 01 Sep 2005 05:58:15 AM CDT -0.462515 seconds
$ ./busybox hwclock
Thu Sep 1 05:58:18 2005 0.000000 seconds
$ hwclock -u
Thu 01 Sep 2005 12:58:24 AM CDT -0.570636 seconds
$ ./busybox hwclock -u
Thu Sep 1 00:58:27 2005 0.000000 seconds
I'd switch this to status "cannot reproduce", but we don't seem to have
one. How about "feedback" (needed)?
Secondly: /var/lib/hwclock/adjtime is kinda loopy, yes. I thought
/etc/adjtime was the norm and that would be a symlink if the system needed
writeable space and /etc wasn't it.
If nobody other than ralphs can reproduce this, it should be closed...
Rob
----------------------------------------------------------------------
landley - 09-01-05 04:12
----------------------------------------------------------------------
Requesting feedback. Can anybody but the original submitter reproduce this
problem?
----------------------------------------------------------------------
Larry - 09-24-05 11:43
----------------------------------------------------------------------
I am able to reproduce this problem on an x86 box, Debian gnu linux,
uClibc
local timezone is Eastern Daylight Saving Time [EDT]
Summary: hwclock -l argument is 1hr faster than correct localtime while
hwclock -u argument is 8 hrs slower than correct UTC time.
Description: On a system with RTC that has the time programmed in
localtime
or UTC, and /etc/TZ contains EST5EDT. The clock quary
produced
following results.
# hwclock --show
Wed September 21 00:11:21 2005 0.000000 seconds <-- Wrong, 1hr faster than
localtime for New York. DST not observed.
# date
Wed September 21 23:11:06 EDT 2005 <-- Correct localtime for New York, DST
observed.
# hwclock -u
Wed September 21 19:11:43 2005 0.000000 seconds <- Wrong, 8hrs slower than
correct UTC.
# date -u
Wed September 21 03:11:13 UTC 2005 <-- Correct UTC Clock
In this instance, the hwclock utility fails to recognize EDT in the time
zone,
and calculates local time as EST5 instead of EDT4. Resulting in localtime
being 1hr faster than correct time.
Contrary to ralphs observation, x86 host produced the same incorrect
result.
Manifestation of the bug was un-noticed because his observation was done
on
eastern standard time.
But the UTC error remain constant at being reported with 2x the applied
timezone, eg instead of UTC-4 for eastern-daylight-saving-time, it
returned
UTC-8. Resulting in UTC time being 8hrs slower than correct UTC time.
Regarding vapier note " instead of looking at `date`, look at the
behavior
compared to the normal `hwclock`:"
Regardless of behavior, I think if hwclock output does not agree with a
correct wall-clock, it is save to accept that the output is inaccurate.
Steps To Reproduce:
Set /etc/TZ file to EST5EDT, reboot the system and syncronize clock with
ntp
client to an EST5EDT capable server.
Additional Information:
It is important to note that this system utilize uClibc which does not
require /etc/localtime, /etc/adjtime, /usr/share/zoneinfo, as opposed to
system utilizing gcc which require those files.
However, the bug will not be noticed unless clock is syncronized. If
sycronization is impossible, the clock can be compared to wall clock and
UTC
time deviation can be calculated manually.
Issue History
Date Modified Username Field Change
======================================================================
02-01-05 11:35 ralphs New Issue
02-01-05 12:33 ralphs Note Added: 0000031
03-16-05 12:27 andersen Assigned To andersen => BusyBox
04-15-05 21:47 vapier Note Added: 0000154
07-16-05 15:19 pgf Note Added: 0000296
09-01-05 04:06 landley Note Added: 0000480
09-01-05 04:12 landley Note Added: 0000481
09-01-05 04:12 landley Status assigned => feedback
09-24-05 11:43 Larry Note Added: 0000575
======================================================================
More information about the busybox-cvs
mailing list