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

2002-11-15-12:20:56 Paul Jarc:
> Bennett Todd <[email protected]> wrote:
> > a good sound comprehensive system solution using clockspeed,
> > sntpdate, and leapsecs.dat with TZ=right/... would also involve
> > stopping clockspeed before each and every leap second,
> 
> I don't think so.  Just make sure you update /etc/leapsecs.dat before
> the leap second actually occurs, and you should be ok from then on.
> clockspeed will keep the system clock moving smoothly, and a TAI clock
> is *supposed* to move smoothly.

You're of course absolutely right, I had that backwards, stopping
clockspeed around a leap second would only be an arguably good idea
if you were deleting /etc/leapsecs.dat, letting your Unix clock get
horked about to keep it at a fixed offset from UTC in the currently
fashionable style.

> >> You might be better off by simply avoiding libtai-based software
> >> on POSIX-clock machines.
> > [...]
> 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. 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.

> Likewise, TAI64[N[A]] labels generated on a TAI-clock
> machine will be misinterpreted on a POSIX-clock machine.

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

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

> 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,
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?

> libtai stuff can work (sort of) with a POSIX clock and
> a non-right/ zone:

Yup. It's not libtai that plagued me, but all the stuff written
using localtime(3) and friends, relying on zoneinfo. The rest of the
system. date(1), for instance.

-Bennett

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE91UaNHZWg9mCTffwRAk+bAJ4+u+AFqvej+/jDH5fpZ6T3fSxVjgCeJwNx
mTNRk6AaNygZ1Gls/SdcQjE=
=LXCE
-----END PGP SIGNATURE-----