On Tue, Dec 14, 2010 at 8:33 PM, John Cowan <cowan@mercury.ccil.org> wrote:
> Alex Shinn scripsit:
>
>> I think providing `current-tai-seconds' is all around a much
>> simpler solution.
>
> Implementations that have Posix time but no corrections will have to
> return #f from current-tai-seconds at all times, making it useless.
> Current-posix-seconds is available in all non-embedded systems in
> modern use.

We're already talking about systems which can and can't
provide time at all, so it's at least reasonable to consider
raising the bar on those systems which provide time.

Previously I confused the restrictions on CLOCK_MONOTONIC
with CLOCK_PROCESS_CPUTIME_ID - CLOCK_MONOTONIC
is guaranteed to give a consistent monotonic clock.  The offset
from the Unix epoch is unspecified, but an approach like the
following can accurately determine this on any system (just
a rough sketch):

  long clock_offset(clockid_t clk1, clockid_t clk2) {
    struct timespec tp1, tp2, tp3;
    long diff1, diff2, offset1=0, offset2=1, syscall_epsilon, i;
    for (i=0; i<10 && offset1 != offset2; i++) {
      clock_gettime(clk1, &tp1);
      clock_gettime(clk2, &tp2);
      clock_gettime(clk1, &tp3);
      diff1 = (tp2.tv_sec - tp1.tv_sec) + (tp2.tv_nsec - tp1.tv_nsec)/1000000;
      diff2 = (tp3.tv_sec - tp2.tv_sec) + (tp3.tv_nsec - tp2.tv_nsec)/1000000;
      syscall_epsilon = (diff1 + diff2) / 2;
      offset1 = diff1 - syscall_epsilon;
      offset2 = syscall_epsilon - diff2;
    }
    return offset1;
  }

So this guarantees TAI on any Linux or BSD system.  I'm
not sure how to do this on Mac or Windows yet (anyone?).

On the other hand, since the alternative is to use a broken clock
anyway, even if you _can't_ compute an accurate TAI value
you can just compute an ambiguous TAI value and you
haven't really lost anything.

--
Alex

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports