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