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


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


   A "date" object is really a representation of time that depends on local
   context (the time zone, daylight-savings time, etc). 


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.