timezone behavior for date and hwclock

[Laurent Bercot]

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