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

Bennett Todd <[email protected]> wrote:
> 2002-11-15-12:20:56 Paul Jarc:
>> Sorry, I meant *other* libtai-based software.  daemontools, runwhen,
>> etc.  TAI64[N[A]] labels generated on a POSIX-clock machine will be
>> non-portable, so it's good to avoid generating them at all, to prevent
>> confusion.
>
> Hmm. Confusion. If all the tools are consistent, I'm not sure how
> having all your TAI 22 seconds off would add confusion.

They'll be consistent with each other, but not with other (TAI)
systems.  But I suppose it wouldn't be any worse than the situation
with a normal POSIX clock, sync'ed by ntpd instead of clockspeed.
Labels generate on those systems will be similarly offset.

> It wouldn't actually be TAI any more, but it'd behave the same,
> internally consistently, except for the duplication of a second when
> there are leap seconds.

There wouldn't be any jumps or repetitions with a clockspeed POSIX
clock.  Your clock would just run fast or slow for a while after a
leap second until it got back into sync with other, jumpy POSIX
clocks.

> For sure, mixing and matching would breed confusion. All one way or
> another. But I'm not completely clear on how bad things would be in
> an all UTC-anchored, leaping clocks setup, where the labels
> manipulated by libtai were consistently 22 seconds off (until the
> next leap second, when they'll be consistently 23 seconds off:-).

Things would become bad when you forget about the difference between
your system and someone else's, and you have trouble correlating your
TAI64[N[A]] labels with theirs.  Hopefully, the 22-second difference
will jump out at you, but maybe not.

>> Also, the interpretation of a given TAI64[N[A]] stamp value will
>> change over time.  After a leap second passes, an old label will be
>> reinterpreted as if there used to be the same UTC-TAI difference as
>> there is now.
>
> Exactly; that's what all normal Unix system users live with now.

Right.  But only if they use TAI64[N[A]] labels, though.  With a POSIX
clock (or a TAI clock, for that matter), a given time_t value has the
same interpretation before and after leap seconds.  They have a
different problem: the leap second itself is not represented by any
time_t value.

>> Naturally, clockspeed on a POSIX-clock machine should not be fed with
>> taiclock.  (That's impossible, actually; feeding it with taiclock will
>> make the clock a TAI clock.)
>
> I disagree. Why couldn't I have a master system, running it's
> POSIX-style clock, running clockspeed (turning it off around leap
> seconds), acquiring time via sntpclock with /etc/leapsecs.dat
> deleted, republishing the resulting lying TAI-22secs via taiclockd,

You could do that.  I was assuming there would be no lies.

> and other POSIX clock machines using taiclock to read that lying
> server and synchronizing their own clocks off the lying TAI-22secs
> feed --- again, turning off clockspeed around leapseconds and doing
> an explicit clockadd rather than an adjust to reset the clock after
> the leapsecond and before reenabling clockspeed?

You don't have to do clockadd, and it wouldn't make much sense on the
clients anyway: their source is the server with a smooth clock, so
they won't get rapidly out of sync.  Just restart clockspeed before
each adjustment; that way, no single run of clockspeed has enough
information to recalculate etc/atto.  Same for the server, I guess.


paul