Re: [Scheme-reports] current-posix-second is a disastrous mistake

[Taylor R Campbell <campbell+scheme@x>]

   Date: Fri, 10 Dec 2010 17:40:32 -0500
   From: John Cowan <cowan@x>

   I have now added `current-jiffy` for elapsed time.

This doesn't help.  It doesn't give me a TAI clock.  It's also not
clear to me what good jiffies are instead of seconds, or even how to
find jiffies on Unix systems.[*]

I recommend a procedure (SECONDS-SINCE-UTC-EPOCH) that returns the
number of SI seconds that have elapsed since 1972-01-01T00:00:00Z.

The clock this procedure represents is a TAI clock, not a POSIX clock.
It does not rewind or slow down during a leap second.  (It is also a
UTC clock, but to write the whole broken-down representation of a UTC
date requires some context, namely the leap second table.  It is also
a US/Eastern clock, but to write the whole broken-down representation
of a US/Eastern date requires some context, namely the leap second
table and the time zone database.)

The UTC epoch is different enough from the POSIX epoch (by 63072000
seconds) that this representation of time is not likely to be confused
with POSIX time, from which it is different probably by something
between 63072000 and 63072100 seconds for the foreseeable future.

Separately, I recommend a procedure (MONOTONIC-SECONDS) that returns
the number of seconds since an unspecified date.  This is not simply a
hardware cycle counter: it is subject to NTP adjustments so that the
time it keeps can be reasonably interpretable as SI seconds.  But it
never runs backward during a program, even if I run `date -r 0'
concurrently.

[*] clock_gettime(CLOCK_MONOTONIC)?  That gives answers in seconds.
clock, or times?  No modern programs use these -- they use getrusage,
which gives answers in seconds.  The Pentium's RDTSC, or a similar
hardware cycle counter?  The conversion between hardware cycles and
seconds is not fixed, as JIFFIES-PER-SECOND needs, particularly on
variable-frequency CPUs such as the one I am using to type this
message right now.  So why not seconds?  For consistent timekeeping,
every system conventionally adjusts any internal representations of
time to seconds anyway.

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