On Thursday, October 16, 2003, at 10:36 AM, der.hans wrote:

> Am 16. Oct, 2003 schw=E4tzte Chris Gehlker so:
>
>> I've been going back and forth between Linux and MacOS a lot and I
>> finally noticed that the time was all screwed up in Linux. So  I =
fixed
>> the problem by setting the system clock from a time server and then
>> doing:
>> hwclock --localtime --systohwclock
>>
>> Now the clock seems to know it's running in local time. I'm still
>> curious, however, about the whole notion of system time being =
separate
>> from the hardware clock time. AFAICT, Linux is the only OS that makes
>> the distinction. I can't quite understand what the distinction is =
for.
>
> UNIX makes the disctinction. The others are incorrect.

I'm not sure that this is completely true. UNIX has Unix time, actually=20=

incompatible versions that differ by a few seconds. Unix time takes=20
either 1970-01-01 00:00:10 TAI or 1970-01-01 00:00:00 TAI as the basis=20=

depending on the library. I get that. But Unix time having a basis that=20=

is measured astronomically at Greenwich doesn't imply that the hardware=20=

clock has to be running on Greenwich time.

> The hardware clock should be constant and should be GMT ( or whatever=20=

> it's
> being called this century ).

This is not actually possible. GMT itself is variable. It changes at=20
the rate of one second / second. ;-)


>  The OS should then adjust to the local
> timezone. If your computer changes timezones it's an adjustment to the=20=

> OS.
> No need to muck with the hardware clock.
>
> MAC OS is now based on *BSD, which, I believe, can also be setup
> MAC OS properly. Can now be setup to use GMT and the timezone offset?


I simply can't tell. The BSD style calls give a correct value but that=20=

really doesn't tell me anything about the hardware clock. I'll have to=20=

write a program that calls time() and gmtime() to find out. Presumably=20=

then I can mess with the time zone settings and see if that has any=20
effect on what gmtime() returns.