Incorrect leap seconds in runit's log timestamps

Incorrect leap seconds in runit's log timestamps

[Lloyd Zusman]

I'm still using runit-1.0.3 (will upgrade soon).

I have just noticed that leap seconds are not properly being accounted for in the timestamps in the log/main/current files for each process that I'm managing.  These timestamps seem to be 11 seconds off from UTC and 10 seconds off from TAI in the other direction.

I believe that TAI and UTC are 21 seconds apart these days, although a while ago, the discrepancy was only 11 seconds.  This leads me to believe that the 11-second offset might have been hard coded into an early version of runit, and then never was changed.

Or am I missing something?

Also, when I upgrade to the latest version of runit, will this leap-second discrepancy change, by any chance?

Thanks in advance.

-- 
 Lloyd Zusman
 ljz@asfast.com
 God bless you.

Re: Incorrect leap seconds in runit's log timestamps

[Joël Riou]

Le mercredi 19 janvier 2005, Lloyd Zusman a écrit :
> I believe that TAI and UTC are 21 seconds apart these days, although a
> while ago, the discrepancy was only 11 seconds.

rant {

No, that is not true. First, a very good link on TAI/UTC questions is 
the following page by David A. Madore :
<URL: http://www.eleves.ens.fr:8080/home/madore/misc/time.html >.

Nowadays, the "difference" between TAI and UTC is *precisely* 32 seconds
(see <URL: http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat >).

But, for some obscure reason, the epoch is considered to be 
1970-01-01 00:00:10 TAI on Unix systems whose clock is supposed to
correspond to TAI timestamps (i.e. the time() function will return the
number of seconds since that epoch (*), whereas with a GMT-time, this
function is supposed to return the number of non-leap seconds since the
epoch (**)). 32-10=22, so the difference between the result of time() in
system with TAI/UTC-times seems to be *22*.

(*) It is the case with right/foo (e.g right/Europe/Paris) glibc timezones.

(**) Due to the fact that the difference between TAI & UTC was not an
integer number of seconds in the beginning of the '70, the epoch
considered by TAI and UTC systems do not match exactly [so why the hell
1970-01-01 00:00:10 TAI was chosen as an origin instead of
1970-01-01 00:00:00 TAI ?!]

To be more specific, provided I understand well both runit and skalibs
tai code, the tai functions assume that time()/gettimeofday() return the
number of seconds since 1970-01-01 00:00:10 TAI, which I think is the
Right Thing ; so if your computer uses another convention (UTC ?), you
can get confusing results. [at this point, my brain is too damaged to
check that this precisely explains your particular trouble...]

}

More seriously, the main trouble in this domain is that, as far as I
know, ntpd assumes that the Unix time is ruled by UTC [which is quite
confusing because the NTP protocol has allegedly some stuff to propagate
the table of leap seconds from servers to clients]. I used to think about
some dynamic library to LD_PRELOAD to ntpd to emulate UTC time()
functions on a system with TAI time, but that would be very ugly.

-- 
Joël Riou

Re: Incorrect leap seconds in runit's log timestamps

[Lloyd Zusman]

Joël Riou <joel.riou@normalesup.org> writes:

> [ ... ]
>
> But, for some obscure reason, the epoch is considered to be 
> 1970-01-01 00:00:10 TAI on Unix systems whose clock is supposed to
> correspond to TAI timestamps (i.e. the time() function will return the
> number of seconds since that epoch (*), whereas with a GMT-time, this
> function is supposed to return the number of non-leap seconds since the
> epoch (**)). 32-10=22, so the difference between the result of time() in
> system with TAI/UTC-times seems to be *22*.

Ah ... OK.  So now I know where the delta of 10 seconds comes from.

[sensation of fog lifting]

Thanks.


> [ ... ]
>
> To be more specific, provided I understand well both runit and skalibs
> tai code, the tai functions assume that time()/gettimeofday() return the
> number of seconds since 1970-01-01 00:00:10 TAI, which I think is the
> Right Thing ; so if your computer uses another convention (UTC ?), you
> can get confusing results. [at this point, my brain is too damaged to
> check that this precisely explains your particular trouble...]

Well, I'm using 'clockspeed' to keep my system clock on TAI, and that
clock is indeed in sync with this resource (at least that's what the
clockspeed utilities seem to say).  However, the 'runit' timestamps are
10 seconds later than what 'clockspeed' tells me.  Perhaps 'clockspeed'
uses 1970-01-01@00:00:00Z as it's base instead of the correct
1970-01-01@00:00:10Z TAI starting point?

Before I go over to the 'tai' mailing list, I want to make sure that I
understand why 'runit' and 'clockspeed' seem to be using different
starting times, so I can try to sound at least halfway knowledgeable
about this when I pose my question on that list.

Any thoughts as to why 'runit' and 'clockspeed' are out of sync?


> More seriously, the main trouble in this domain is that, as far as I
> know, ntpd assumes that the Unix time is ruled by UTC [which is quite
> confusing because the NTP protocol has allegedly some stuff to propagate
> the table of leap seconds from servers to clients]. I used to think about
> some dynamic library to LD_PRELOAD to ntpd to emulate UTC time()
> functions on a system with TAI time, but that would be very ugly.

Well, I left the ntpd world and I'm sticking with 'clockspeed'.  But
given this 10-second discrepancy, it too seems to have its problems
... or at least some confusing complications.



-- 
 Lloyd Zusman
 ljz@asfast.com
 God bless you.

Never mind! (was: Incorrect leap seconds in runit's log timestamps)

[Lloyd Zusman]

Lloyd Zusman <ljz@asfast.com> writes:

> Any thoughts as to why 'runit' and 'clockspeed' are out of sync?

... and I figured out the answer to that question: the person who messed
this up was me.  I had written my own TAI-to-human-readable filter which
didn't take the 01-01-1970@00:00:10Z start time into account ... I was
taking the low-order 32-bits of the TAI value and incorrectly treating
as a standard unix timestamp.

I had forgotten that I was using my own filter to read the timestamps.

Thanks again for your help and patience.

-- 
 Lloyd Zusman
 ljz@asfast.com
 God bless you.