tai confusion

From: Paul Jarc <prj_at_case.edu>
Date: Wed, 07 Jan 2015 02:40:18 -0500

I'm finally digging into a long-standing bug exhibited by runwhen
(rw-match computes a timestamp 10 seconds too early), and I think the
problem is in skalibs. tai_from_sysclock() adds 10 seconds depending
on whether skalibs is configured with --enable-tai-clock. But
tai_from_timeval doesn't, so they're inconsistent. I think they're
actually both wrong: the correct behavior for both should be to
unconditionally add 10 seconds, and conditionally add leap seconds
depending on --enable-tai-clock

No matter whether you use a POSIX or TAI clock, the epoch is the same:
1970-01-01 00:00:10 TAI (which is 00:00:00 UTC). So the 10 seconds
need to be added in either case.

With a POSIX clock and no --enable-tai-clock, we need to add the
appropriate amount of leap seconds or else the tai_t values we
generate will differ from those simultaneously generated on a system
using TAI-10 and --enable-tai-clock. (This means that on a POSIX
system, converting future times to TAI will give you wrong results
after the time when the as-yet-unknown next leap second will be

Received on Wed Jan 07 2015 - 07:40:18 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:38:49 UTC