> Some quick responses to quick comments.

OK, here are my quick replies to your your quick responses to my quick
comments.

> It doesn't assume this many seconds in a year;

Note: you mean "day" not "year" (i.e. a day is 86400 seconds roughly).
You made this error in the SRFI also.

>  it defines this many
> seconds in a year. One advantage is that you get a deterministic
> algorithm (as you say). Another important advantage is that you can
> treat time as a number, and use standard mathematical operators. The
> disadvantage is that drift from UTC, as you say.

This is not a disadvantage, it is a blatant error!  If you call something
"universal time" it better correspond to UTC.  Common Lisp made a big
mistake here.

> Sorry, I missed the last Scheme Naming Convention--when was it held?
> Seriously, I don't have a problem changing the names, but perhaps you
> could point out a "here's how to name Scheme procedures" document; I'd
> appreciate it.

Just the R5RS and predecessors, with (current-input-port) et al.  My
model for the computer's clock is that there is an implicit parameter
to the program that is updated continuously by the hardware.  So in
this respect it is very much like the implicit parameters that are the
current input port, et al.

> The main reason is just that bug-a-boo of mine to be consistent with
> Common Lisp; I'll reconsider this. I've found the CL approach clumsy in
> just this way.

But it would still be consistent if you specified that the resolution
is at least 1 second, because you can always strip the fractional part
if you don't want this (and your Common Lisp style accessors could do
this by default).

> > 5) Instead of the "multiple value" interface of decode-universal-time
> > I prefer single-value accessors of the kind:
> >
> >   (universal-time-second ut)
> >   (universal-time-minute ut)
> >   ...
> >
> > and also (universal-time-second ut) would return a real, possibly
> > inexact.
> >
>
> Maybe. Perhaps you could give me reason beyond 'I prefer'?

A multiple value interface is clumsy and slow because if you want a
single component you have to extract them all (and there are many
components) and this is a common case (get the day of the week, or the
year).  Moreover you have to remember all the components and their
order.  For 2 or 3 components that's doable, but I couldn't do it
without the documentation for 9.  Finally, the interface lacks
modularity and upgradability.  If as an implementor I'd like to add a
component (such as microseconds) then to keep the multiple value
interface I'd have to change all the code that calls
decode-universal-time and that may not be possible.

> Again, CWCL. 1-1-2000 seems like a poor choice because time isn't
> defined before this number. 1-1-1970 might be fine.

Now this is a major bug.  I was born in 1961.  I want to be able to
represent my birthday to put in a database, etc or simply to figure
out on which day of the week I was born.  In fact, I'd like to do that
for any point in time.  Bignums, positive and negative, allow us to do
this easily.  What is the problem here?  The SRFI doesn't say there is
an upper limit, so you have to use bignums anyway, no?  Once again
Common Lisp got it wrong.

> The main reason is insist that it be a number is one can use standard
> mathematical operators on them, without converting. You don't need a
> special time>, etc.

I'm sure you are aware of all the advantages of abstract datatypes and
all the disadvantages of concrete ones.  The extra calls to
the conversion functions are well worth it.

Marc