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