>       > (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.
>
> I was, indeed, careful to define it.  It is Posix time, which is
> sometimes inappropriately called UTC time (but actual UTC time includes
> leap seconds and has either 60 or 61 seconds per minute).  Because this
> is the clock used for file times, I think we need to keep at least the
> seconds portion of it, but I see no reason not to have the nanoseconds
> (or millisexonds, whatever) as well.

The tasks re: file timestamps I can think of are:

---

1. Read the timestamp of file F (up to nanosecond precision). This does
not present problems, as we are just reading an old timestamp.

2. Decode timestamp T into year, month, date etc. or convert to another
timescale. Also not a problem.

3. Set the timestamp of file F to match timestamp T which we got from
another file and possibly manipulated with some arithmetic. This is also
fine since we can say timestamp T is what it is and doesn't need to have
any relation to timekeeping in the present.

---

4. Set the timestamp of file F to the current time. I would rather have
a procedure to do precisely this (or a special argument, like giving #t
or #f instead of a numeric timestamp, to denote the present moment).
It's trickier to first get the current time from a C function, then
introduce some delay by going around between Scheme and C, finally
calling another C function to set the timestamp.

5. How old is timestamp T? I would have a procedure (age timestamp) that
returns the difference between the current time and the timestamp as
accurately and precisely as it can.

---

The horizontal lines above emphasize that timestamps are problem-free,
but the problems start when the present moment is factored into the
equation. My intuition would favor having an array of
"do-something-with-the-present-moment" procedures instead of having a
procedure to get the current timestamp and then use it manually. This is
an unusual and even eccentric approach but it feels right to me. I'll be
very interested to hear arguments to the contrary.

You could say there are problems like "set a file's timestamp to 6
months in the past". Maybe encode and decode procedures for file
timestamps are sufficient. These are not finished thoughts.