[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ntpdate, /etc/timezone et all.



On Sun, Mar 18, 2001 at 05:38:07PM -0500, Stan Brown wrote:
> On Sun Mar 18 16:11:55 2001 Carel Fellinger wrote...
...
> >I'm no time expert, just thinking that maybe al is swell afterall.
> >So could you post the outcome of the following commands?
> >
> >   # date && hwclock --show
> 
> Script started on Mon Mar 19 01:18:10 2001
> yogi:~# date
> Mon Mar 19 01:18:13 EST 2001
> yogi:~# hwclock --show
> Mon Mar 19 01:18:21 2001  -0.495009 seconds
> yogi:~# echo $TZ
> 
> yogi:~# cat /etc/timezone
> US/Eastern
> yogi:~# 
> Script done on Mon Mar 19 01:18:41 2001

I don't know what that Script is doing, but if it merely contains
the commands I proposed, all looks swell.  But...

Ofcourse I don't know what the real time is over there:), but it is
close to what it is here now, so it probably isn't what it says it is.

...
> 	OK, I'm totaly confused. There are 3 things involved here, as I see it. The
> 	hardware clock, which should be set to UTC. The kernels view of time, which
> 	should be the same as the hardware clock modified by the value of
> 	/etc/timezone, and the "user" view of time which should be UTC modifiedby
> 	whatever they have set TZ to, or if they have not set it, modified by what's in
> 	/etc/timezone.
> 
> 	Have I got that correct?

Yep.  The hardware clock is used at boot time to give the Kernel's
soft-clock a reasonable start value.  From there on it isn't used at
all by the kernel.

*date* shows the time taken from the kernel's soft-clock and displays
it in local time format as defined by /etc/timezone or env. var TZ.

*hwclock --show* shows the time taken from the hardware clock and
again shows it in local time format as defined by /etc/timezone or
env. var TZ.

> 	If so why does my machine think it's 1 oclock tomorow morning? It's really
> 	about 18:30 EST.

Because both your hardware and your doftware clocks are wrong:)

> 	Please explain what I'm looking at wrong here.

Nothing, it's just time to use *ntpdate -q ntp.some.server* to see how much
your clocks have drifted from the real time.  Do something like:

   date && /usr/sbin/ntpdate -q ntp.iae.nl ntp.chello.nl && date

And show the output.

[[ just guessing, but after using *ntpdate ntp.some.server* do you
   save the then correct soft-clock time in the hardware clock with:

        hwclock --systohc

   If so, the only thing left is that the time is so far off that
   ntpdate refuses to correct the time, w'll see.
]]

-- 
groetjes, carel



Reply to: