Should time stuff be in scope for this SRFI? I would leave it out,
except for file timestamps. The rationale is as follows.

 >(process-times)
 >Returns four values:
 >user CPU time in clock-ticks
 >system CPU time in clock-ticks
 >user CPU time of all descendant processes
 >system CPU time of all descendant processes
 >Note that CPU time clock resolution is not the same as the real-time
 >clock resolution provided by time+ticks.

What is CPU time -- If a process runs code on several cores, are all the
cores counted? If not, does it count the core making the query or the
"main" core of the program? What about hyper-threading (e.g. a dual-core
processor having 4 "virtual cores")? How does one distinguish between
user and system time on microkernel OSes like QNX, GNU HURD, etc.?

What would be the applications of this procedure, and can we specify it
so that it serves their purpose? Process monitor programs like "top" and
"htop" are notorious in that they basically have to be re-implemented
for each OS they support. There is little in the OS APIs that is both
portable and unambiguous.

 > (cpu-ticks/sec)
 > Returns the resolution of the CPU timer in clock ticks per second.
 > This can be used to convert the times reported by process-times to
 > seconds.

What about CPUs that can adjust their clock frequency while running?
What about multi-core systems? What about counter wraparound?

What would be the applications of a CPU tick counter, and can we serve
them? The only one I can think of off the top of my head is profiling
the execution time of code. That application would be better served by a
dedicated profiling API. Then the Scheme implementation would be free to
use whatever techniques make for the most accurate profiling.

More generally, portable interfaces to microsecond/nanosecond precision
timers are questionable (i.e. I would put the burden of proof on whoever
proposes them to prove that they are reliable and useful for some
application).

Timestamps that have been recorded at some previous time are OK (e.g.
file timestamps). Then we are simply reading an old timestamp that isn't
dependent on accuracy of any timer measuring the current time. But
anything that depends on sub-second timing _in the present moment_
should give us a little pause (no pun intended :)

 > (time+ticks) ---> [secs ticks]
 > The current time, with sub-second resolution. The time is returned as
 > elapsed seconds since the Unix epoch excluding leap seconds, plus a
 > number of sub-second "ticks."

I would recommend being more explicit with the time APIs. Dealing with
time is like quicksand (even more so than OS APIs in general). It's best
to specify precisely what kind of timestamp we want and assure ourselves
that we can reliably get one.

There are several clock sources which all have their own uses:

* Any monotonic (never decreasing) clock source, used as a counter.
* Human time in TAI (can decrease when adjusted, counts leap seconds).
* Human time in UTC (can decrease when adjusted, skips leap seconds).
* Human time in local time (timezone, daylight saving time).
* Various profiling and tick timers close to the hardware.
* Vectored clocks for network applications.

Good references for time stuff include:

Implementing POSIX clocks under Linux (Markus Kuhn)
https://www.cl.cam.ac.uk/~mgk25/posix-clocks.html

The Long, Painful History of Time (Erik Naggum)
http://naggum.no/lugm-time.html

D. J. Bernstein's time pages:
https://cr.yp.to/time.html