0000074: hwclock arguments -u and -l inverted - BusyBox Bug and Patch Tracking

Notes
(0000031) 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.

(0000154) 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 ?

(0000296) pgf 07-16-05 15:19 edited on: 09-27-05 08:29	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. [ amended -- reading a recent hwclock manpage, i see that localtime should be assumed if the adjtime file cannot be found. -pgf ]

(0000480) 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

(0000481) landley 09-01-05 04:12	Requesting feedback. Can anybody but the original submitter reproduce this problem?

(0000575) Larry 09-24-05 11:43 edited on: 09-24-05 15:50	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 glibc 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.

(0000579) pgf 09-27-05 14:33	the current svn code behaves the same as the system (glibc-based) hwclock from util-linux on systems running either localtime- or UTC-based clocks. i think some of the confusion is that the "-l" ("--localtime") option to hwclock doesn't really 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 "hwclock --utc", or if it's programmed in UTC, and you use "hwclock --localtime", you're lying, and will get incorrect time results. furthermore, if your RTC is programmed for localtime, and your system doesn't reboot after DST takes effect, then there may be a one-hour discrepancy between the values shown by "hwclock --localtime" and "date".

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
09-24-05 11:47	Larry	Issue Monitored: Larry
09-24-05 15:50	Larry	Note Edited: 0000575
09-27-05 08:29	pgf	Note Edited: 0000296
09-27-05 14:33	pgf	Status	feedback => closed
09-27-05 14:33	pgf	Note Added: 0000579
09-27-05 14:33	pgf	Resolution	open => no change required

Relationships