Re: Is 'right' wrong?

Lloyd Zusman <[email protected]> wrote:
> The reason that I saw the discrepancy between 'before' and 'after' in
> the first email message, below, is because I had forgotten to do this
> after changing the /etc/localtime and /etc/leapsecs.dat files:
>
>   sntpclock 209.51.161.238 >/usr/local/clockspeed/adjust

Hmm.  sntpclock uses leapsecs.dat, but not localtime/$TZ.  clockspeed
uses neither.  And although localtime/$TZ changes take effect
immediately, I wouldn't expect clockspeed to correct a 22-second error
too quickly when you add/remove leapsecs.dat.  Anyway...

>   using clockspeed
>   using /etc/leapsecs.dat
>   using right/ timezone descriptors
>
>   Result: clock is set to TAI (based on Date: field in emails),
>           and dates/times display as UTC in the
>           'date' and 'sntpclock' commands

To avoid any confusion, I would put it differently, avoiding any use
of "UTC" or "TAI".  time_t counts both leap and non-leap seconds, due
to clockspeed+sntpclock+leapsecs.dat; localtime() has the same
expectation due to localtime/$TZ.  Therefore your human-readable
format should match what other self-consistently-configured machines
say, regardless of whether they count leap seconds in time_t.

You could confirm this by running
"perl -le '$x=time; print $x; print scalar localtime $x'" on two
machines at the same time and comparing the results.

>   using clockspeed
>   using /etc/leapsecs.dat
>   not using right/ timezone descriptors
>
>   Result: clock is set to TAI (based on Date: field in emails),
>           and dates/times display as TAI in the
>           'date' and 'sntpclock' commands

I would say time_t counts leap and non-leap seconds, but localtime()
thinks it only counts non-leap seconds, so the human-readable format
appears to be 22 seconds ahead of what other machines say.

>   using clockspeed
>   not using /etc/leapsecs.dat
>   not using right/ timezone descriptors
>
>   Result: clock is set to UTC (based on Date: field
>           in emails), and dates/times display as UTC
>           with the 'date' and 'sntpclock' commands

I would say time_t counts only non-leap seconds, and localtime() has
the same expectation, so your human-readable format matches what other
machines say.

>   using clockspeed
>   not using /etc/leapsecs.dat
>   using right/ timezone descriptors
>
>   Result: clock is set to UTC (based on Date: field in emails),
>           and dates/times display as UTC - 22 seconds in the
>           'date' and 'sntpclock' commands

I would say time_t counts only non-leap seconds, but localtime()
expects it to count leap seconds as well, so your human-readable
format will appear to be 22 seconds behind what other machines say.

> So ... it seems to be that when using clockspeed, /etc/leapsecs.dat
> affects the system clock,

If you use sntpclock, yes.  Not if you use taiclock.  The time values
given in NTP's network messages only count non-leap seconds, so if you
want your local clock to count leap seconds, then you need a local
table to add leap seconds to the value from the server.  With
taiclock, the network messages already include the leap seconds.

> and (in all cases, not just with clockspeed) the right/ timezone
> descriptor affects the offset from the system clock that is applied
> by various system utilities like 'date'.

I don't know if "offset" is quite the right word, but yes, it affects
the mapping between time_t values and broken-down values.

> The use of /etc/leapsecs.dat currently adds 22 seconds to the system
> clock;

More precisely: it tells sntpclock that the system clock counts both
leap and non-leap seconds, so sntpclock adds (currently) 22 to the
values it gets from NTP servers and compares the result to time().

leapsecs.dat is also used by the libtai functions that convert between
broken-down values and time_t.

> and right/ timezone descriptors currently subtract 22 seconds from
> the date/time value that would be displayed by various system
> utilities.

Yes.

> What I want is for my system clock to be set to TAI, and for 'date',
> etc., to also display that same time value.  Hence, Scenario 2 is for
> me.

I don't think scenarios 2 and 4 are for anyone.  If you want your
system clock to be continuous, advancing by 1 for each physical
second, then use scenario 1.  Also note that giving clockspeed
adjustments from sntpclock with and without leapsecs.dat will confuse
clockspeed about how fast your hardware clock runs.  So first set
leapsecs.dat and localtime/$TZ the way you want, remove clockspeed's
etc/atto if you think it's too screwed up, then restart clockspeed,
and start giving it consistent adjustments.


paul