> I prefer time-comparison names without terminal question marks.
   > I think these
   >   (time= t1 t2)
   >   (time< t1 t2)
   > are clearer than these
   >   (time=? t1 t2)
   >   (time<? t1 t2)
   > The terminal ? is redundant, hence unnecessary clutter.

   But so is string=?, char=?, etc.  Here I prefer consistency with RnRS
   than independent elegance because you don't have to constantly wonder
   if you should add the question mark or not. (But I agree that dropping
   the ? is more elegant.)

Yes, you have a point. But let us move forward -- I'd like to lobby
for starting a *new* convention. No irritating terminal ?'s on comparison
functions -- <=, <, =, >, >= predicates.

   > You may wish to look at the scsh time spec, at the above URL. It has some
   > flaws, due to its close binding to the Posix API, but also has some
   > nice features. There are two time representations -- time (seconds), and
   > date (broken-out time -- y/m/d/h/m/s etc.) The API is quite simple:
   >      (date)         -> the current date (a struct)
   >      (date tm [tz]) -> the date for time TM in timezone TZ
   >
   >      (time)         -> the current time (an integer)
   >      (time dt)      -> the time for date DT

   Except for the names (I would prefer (current-date) and
   (current-time)) and that time is represented concretely by an integer,
   I like this approach.  To me a "time" object is an absolute point on
   the time line, and is independent of time zones, etc (and also
   independent of relativity but that's another topic...).

Yep!

   A "date" object is really a representation of time that depends on local
   context (the time zone, daylight-savings time, etc).

Yep!

However, if you use the names CURRENT-DATE & CURRENT-TIME, you can't make
each function work as both the current-time fetcher and converter with
optional arguments, as I did. I think using DATE & TIME makes for a very
small, simple interface. You simply use the name corresponding to the kind
of thing you want; if you are doing a conversion, then you give the parameter.
End of story.

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