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