Date: Fri, 10 Dec 2010 17:40:32 -0500 From: John Cowan <[email protected]>
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 [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
