[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. 
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
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

$ ./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 --
does it assume this file exists?  if the file doesn't exist, it assumes
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...


 landley - 09-01-05 04:12  
Requesting feedback.  Can anybody but the original submitter reproduce this

 Larry - 09-24-05 11:43  
I am able to reproduce this problem on an x86 box, Debian gnu linux,
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
              or UTC, and /etc/TZ contains EST5EDT. The clock quary
              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

# 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
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
Manifestation of the bug was un-noticed because his observation was done
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
UTC-8. Resulting in UTC time being 8hrs slower than correct UTC time.
Regarding vapier note " instead of looking at `date`, look at the
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
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
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