Email list hosting service & mailing list manager

Proposed changes to SRFI-19 shivers@xxxxxx (24 Apr 2000 03:06 UTC)
Re: Proposed changes to SRFI-19 Marc Feeley (24 Apr 2000 14:45 UTC)
Time shivers@xxxxxx (24 Apr 2000 15:33 UTC)
Re: Time Marc Feeley (24 Apr 2000 16:26 UTC)
RE: Time Will Fitzgerald (24 Apr 2000 16:41 UTC)
Note #1: The basic representation of time Will Fitzgerald (13 Jun 2000 20:07 UTC)

Re: Proposed changes to SRFI-19 Marc Feeley 24 Apr 2000 14:45 UTC

> 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.)

> 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...).  A "date"
object is really a representation of time that depends on local
context (the time zone, daylight-savings time, etc).  I see no problem
in using a "time" object to program a deep-space probe, but would have
a hard time using a "date" object...  So I would suggest separating
the two concepts in SRFI-19.

Marc