Note #1. The basic representation of time.

"Time" is an absolute (Newtonian) point in time. There are a number of
standard time representations that should be captured:

- TAI (international atomic time). Measures constant, real time.
- UTC (coordinated universal time). TAI adjusted by leap seconds.
- Monotonic time. Time from some point in time since this computer was
last reset.
- Time in current thread. Time from some point in time since this thread
ran.
- Time in current process. Time from when this Scheme session started.
- Durations. Arbitrary amounts of time.
- Other, implementation specific representations (time spent in GC,
etc.)
- Other, user-defined representations (mission elapsed time, etc.).

You should be able to query the representation for its resolution.

"Time" should be its own data type, with three fields:

The 'type,' i.e., the representation type described above,
A number of seconds, an integer, representing the number of whole
seconds since/before the 'epoch' or start of the point in time,
A number of nanoseconds, an integer (0 to 999,999,999) representing the
partial seconds. Leap seconds, though, are represented in the nanosecond
field as 'overflow' to 1,999,999,999.

Conversion procedures required:

UTC<->TAI<->Date
Monotonic->UTC
Monotonic->TAI
Monotonic->Date

Getting the current time is only required to provide a 'best effort'.

Some justifications:

I won't try to justify each of the representations, except that I do
think it's important to allow a 'user defined' time types.

Using seconds/nanoseconds provides a clean, consistent, precise,
representational scheme that is likely to work for a long time
(milliseconds may be too little; attoseconds too much). Querying the
resolution allows you to know how much really matters.

Representing leap seconds as 'overflow' means that the 'seconds' part of
TAI and UTC forms will be the same as far as conversion routines go.

Carrying the 'type' with the datum helps prevent invalid operations
(like adding two TAI times).

Relativity isn't considered because, well, then I'd have to understand
relativity, and I'm just a liberal arts convert :)

It's difficult to get the current time, especially in the absence of
time servers, etc.

Much of this is based on "Proposed new <time.h> for ISO C 200X"
http://www.cl.cam.ac.uk/~mgk25/c-time/.

--
Will