>> Making time a distinct datatype, instead a number, has
> plusses & minusses.
> I have mixed feelings.
>   - Plusses
>     Increased error detection
>     Can represent time as pair of ints -- second & subsecond
> precision.
>        ...which allows hiding leap seconds in the subsecond part, a la
>        Kuhn's proposal.
>
>   - Minusses
>     Cannot use arithmetic ops to do time calculations -- very annoying
>     Must cons to generate a time; not low overhead.
>
> The second minus -- that you must allocate storage to get a
> time stamp -- is
> not *so* important, because you can always have an alternate,
> purpose-designed
> low-overhead interface, of the TIME+TICKS variety, which can
> return what
> Markus Kuhn calls "process" time.
>
> However, I'm not so comfortable with the first minus. Is
> there to be some
> form of conversion between time & seconds?
>
> I suggest there are enough open issues to warrant extending
> the discussion
> period of this SRFI. Time is tricky.
>     -Olin
>

I don't have time to think through all of Olin's suggestions and
corrections. I've started looking at Kuhn's page.

I do have time->seconds, and seconds->time procedures, with
implementation specific epochs, in the proposal.

Kuhn makes a strong argument for distinguishing between TIME_TAI
(essentially, time, including leap seconds) and TIME_MONOTONIC
(essentially, the number of seconds since some epoch)--e.g., 'after 10
seconds' means different things. (And, if these are added, then a
TIME_PROCESS and TIME_THREAD (in Kuhn's terms) make sense again.)

I'll probably add a TIME_MORONIC type, too, to capture all of the math
errors I keep leaving in :)

I'll try to make an issues list in the next few days. If people would
like to send me suggestions for the list, please do so directly or via
the mail list as a whole.

--
Will (with apologies to Olin for triplicates)