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

Bennett Todd <[email protected]> wrote:
> 2002-11-14-17:34:43 Paul Jarc:
>> 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:
>
> I _think_ that POSIX requires that time(2) skip leap seconds,

Yeah, I guess that could be considered a moving epoch.  I wasn't
thinking of it that way.

> 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.  The leap second will only make a
difference in sntpclock's interpretation of the NTP times it gets from
the network.  sntpclock won't see any time stamps affected by the leap
second until the leap second actually happens, so you just need to
update leapsecs.dat before that.  (And if you feed clockspeed from
taiclock instead of sntpclock, you don't even need to update
leapsecs.dat first.  (Well, not for the sake of clockspeed, but it
should be updated as soon as possible anyway, for the sake of other
things.))

> If anything except djb libtai clients used TAI, I'd find this a
> greater concern. Do you know of any other software using TAI?

No.

>> You might be better off by simply avoiding libtai-based software
>> on POSIX-clock machines.
>
> Given a machine might have to be a POSIX-clock machine because,
> e.g., you want consistent log timestamps enterprise-wide, and some
> devices in the enterprise might be forced to stay POSIX, I'd _still_
> like to use clockspeed on it.

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.  Likewise, TAI64[N[A]] labels generated on a TAI-clock
machine will be misinterpreted on a POSIX-clock machine.  If the only
TAI communication on your POSIX-clock machine is between sntpclock and
clockspeed, you should be more or less ok.

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.

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

> Maybe it'd make the very most beautiful (or the least ugly, take
> your pick :-) sense, in such a case, to just reach into sntpclock
> and butcher its brain, blinding it to leapsecs.dat, so it syncs
> POSIXly, but leave leapsecs.dat in place and let the rest of the
> libtai machinery Rest In Peace.

If you're not using any other libtai software, then you might as well
just remove leapsecs.dat; that's easier.  If you are using other
libtai software, you'll have trouble, since sntpclock's interpretation
of the system clock won't agree with everything else's.  My earlier
commands were not showing what I thought they did, because I was using
a right/ zone.  libtai stuff can work (sort of) with a POSIX clock and
a non-right/ zone:
# mv leapsecs.dat{,-}; \
> TZ=US/Eastern DELAY=1 HOUR==22 caldelay sh -c 'date -d "+$DELAY seconds"'; \
> mv leapsecs.dat{-,}
Fri Nov 15 17:00:00 EST 2002

Right on the hour.


paul