scheme.time- R7RS time
Exports bindings of R7RS
(scheme time) library.
From R7RS programs,
those bindings are available by
(import (scheme time)).
Returns a real number represents the number of seconds since
the midnight of Jan. 1, 1970 TAI (which is 23:59:52, Dec 31, 1969 UTC, that
is, -8 seconds before Unix Epoch.) Number of leap seconds were
inserted since then, and as of 2014, UTC is 35 seconds behind TAI. That means
the number returned is 27 seconds larger than the unix time,
which is returned from
The reason that R7RS adopts TAI is that it is monotonic and suitable
to take difference of two timepoints. The unix time returned by
sys-gettimeofday are defined in terms of
UTC date and time, so if the interval spans across leap seconds,
it won’t reflect the actual number of seconds in the interval.
(The precise definition is given in section 4.15 of
IEEE Std 1003.1, 2013 Edition, a.k.a Single Unix Specification 4.)
However, since we don’t know yet when the next leap second happen, the current implementation just uses a fixed amount of offset from the unix time.
Just be aware the difference, or you’ll be surprised if you
pass the return value of
current-second to the UTC time
formatter such as
sys-strftime, or compare it with
the file timestamps which uses the unix time. You can convert
between TAI and UTC using srfi-19 (see 日付).
Returns an exact integer measuring a real (wallclock) time elapsed
since some point in the past, which does not change while a
process is running. The time unit is
The absolute value of current jiffies doesn’t matter, but the difference can be used to measure the time interval.
Returns a constant to tell how many time units used in
consists of a second. Currently this is 10^9 on 64bit architectures
(that is, nanosecond resolution) and 10^4 on 32bit architectures
(100 microseconds resolution).
The resolution for 32bit architectures is unfortunately rather coarse, but if we make it finer the current jiffy value easily becomes bignums, taking time to allocate and operate, beating the purpose of benchmarking. With the current choice, we have 53,867 seconds before we spill into bignum. On 64bit architectures we have enough bits not to worry about bignums, with nanosecond resolution.
If you want to do more finer benchmarks on 32bit machines,
you need to roll your own with