Re: What TZ do you use to get right time w/ clockspeed?

Bennett Todd <[email protected]> wrote:
> 2002-11-14-16:43:30 Paul Jarc:
>> Bennett Todd <[email protected]> wrote:
>>> remove leapsecs.dat
>>
>> This will break libtai.
>
> That makes sense; the "fix" in question is breaking clockspeed's
> ability to hork the system clock around to TAI

sntpclock's, to be precise.  sntpclock gets an NTP time (a count of
non-leap seconds since the NTP epoch) from the network and uses
leapsecs.dat to add leap seconds to it.  It also adjusts for the NTP
epoch vs. Unix epoch and then outputs the difference between the NTP
time and the current system time.  clockspeed itself doesn't know or
care about epochs or leap seconds; it just maintains an idea of where
the clock is right now, and where it ought to be.  clockspeed does
(sort of) assume that the clock is supposed to move smoothly, and the
POSIX clock does not move smoothly, but that won't ever throw you off
by more than a second.

I think.

> I.e., wouldn't the other TAI timestamps you'd be inclined to feed to
> libtai have been based on the same assumption that the system clock
> is marching to TAI,

Yes.  tai_unix() has a hard-coded interpretation of the system clock.
The conversion of a time_t to a struct tai assumes that the system
clock counts all seconds since the Unix epoch, not just non-leap
seconds.  The POSIX clock would count only non-leap seconds.

> rather than to the variable, moving-epoch UTC-10secs or whatever it
> is that POSIX mandates?

Nobody uses a moving epoch; anything that moves is not an epoch at
all.  POSIX and the Olson right/ zones use the same epoch, I think:
$ TZ=UTC perl -le 'print scalar localtime 0'
Thu Jan  1 00:00:00 1970
$ TZ=right/UTC perl -le 'print scalar localtime 0'
Thu Jan  1 00:00:00 1970

> Another, which might be more acceptable in some contexts, would be
> to leave the system clock behaving as POSIX mandates. Removing
> /etc/leapsecs.dat seems to do that.

That will put your system clock in sync with other POSIX clocks.  But
when a leap second comes along, NTP-sync'ed machines will jump; your
clockspeed-regulated clock will move smoothly to the new time, after
you've fed it a correction from sntpclock.  It would be best to
restart clockspeed just before giving it this adjustment, to ensure
that etc/atto isn't distorted.

Your TAI64[N[A]] labels will not agree with those from true TAI-clock
machines at the "same" time, though.  I suppose you could patch your
libtai to correct for this, so that its time_t -> struct tai
conversion would account for time_t not counting leap seconds.  But
that correction would require the same data that's in
/etc/leapsecs.dat.  You might be better off by simply avoiding
libtai-based software on POSIX-clock machines.  TAI64[N[A]] labels are
supposed to be portable; if you don't have libtai here, you certainly
won't misinterpret them. :)

> In this world, your system clock is POSIX, and all the objects you
> pass around that you call TAI, at least in the djb software world
> (I've never seen anything else that uses TAI so far), would actually
> not be TAI, they'd be TAI-wrapped POSIX time, with inconsistent
> epoch and all, but at least consistently processed.

I think that's right.


paul