Re: Is 'right' wrong?

[email protected] (Paul Jarc) writes:

> Lloyd Zusman <[email protected]> wrote:
>
>> [ ... ]
>>
>>   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.

But that is not what happens on my machine in this case.  In this
scenario, there is a 22-second discrepancy between my time_t value and
the human-readable value.

How could this be?

On my machine, I want both the system clock _and_ the human readable
values "to be continuous, advancing by 1 for each physical second" (to
quote what you wrote below).  In this scenario, this is only true for my
system clock.  As I mentioned above, this scenario causes the
human-readable values to be (currently) 22 seconds earlier than the
time_t values.


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

But in this scenario, the time_t and the human-readable value are
exactly the same on my machine.

Same question as above:  how could this be?


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

Yes, it matches other machines that count only non-leap seconds.


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

They are 22 seconds behind what other non-leap-second-counting machines
say, and 44 seconds behind what leap-second-counting 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.

Do you know of any reliable public taiclock servers?  I'd rather go
straight to one of those, if possible.


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

But what I call "Scenario 1" gives me this:

  system clock is continuous and advances by 1 for each
  physical second

  human-readable times are (currently) 22-seconds earlier
  than the system clock

As I have mentioned above, I instead want the following, which is what I
get when I make use of what I call "Scenario 2":

  system clock is continuous and advances by 1 for each
  physical second

  human-readable times are exactly the same as the system
  clock



-- 
 Lloyd Zusman
 [email protected]
 God bless you.