> - date assumes the rtc clock is kept in UTC, and always shows local time. > Unless you ask to see UTC time by adding -u. > - hwclock counts on the user to say whether the rtc clock is kept in local > time (-l) or in UTC (-u). If used correctly, it will always show local time. > If the rtc clock is kept in local time, there's no way to find out UTC time > using only the hwclock command. Therefore I now choose to keep it in UTC > time. The implications are: when using the hwclock arguments -w and -s (set > hwclock to systime and vice versa), the $TZ variable should be unset.
Yes, you got it right. Note that POSIX more or less requires the system clock to be set to UTC. Some people (including A. David Olson, DJB and me) think that it's better, and almost permitted by POSIX, to set your system clock to TAI-10 instead of UTC, to get a linear time scale, and do leap seconds calculations in user space. Nobody, except Microsoft developers, thinks that it's a good idea to set your system clock to local time. Everybody in the Unix world agrees that it's better to set your system clock to Greenwich time and use a timezone library to get applications to display and handle local time correctly. Basically, "hwclock -l" should not even exist, because it accommodates broken configurations. The real dilemma about the system clock isn't between UTC and local time, it is between UTC and TAI-10. The gory details can be found here : http://www.madore.org/~david/computers/unix-leap-seconds.html This page advocates the use of the TAI-10 setup : http://cr.yp.to/proto/utctai.html Here is where I sum up the two possible settings : http://www.skarnet.org/software/skalibs/flags.html#clockistai -- Laurent _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
