[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposed changes to SRFI-19

This page is part of the web mail archives of SRFI 19 from before July 7th, 2015. The new archives for SRFI 19 contain all messages, not just those from before July 7th, 2015.

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