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

Re: Time

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.

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

Moving forward is not always a good thing, for example if you are on
the edge of a precipice.  ;-) However, if you can convince the RnRS
authors to drop the ? on string=?, etc (but not on pair? etc) I'm 100%
behind you (... on the edge of the precipice).

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

I was suggesting (current-date) and (current-time) to get the date and
time, and (date->time date) and (time->date time) to convert between

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

Also, you can overload (mutex-lock! mutex timeout) so that it accepts
absolute timeouts (a time object) and relative timeout (a real
representing a number of seconds from now).

>   - Minusses
>     Cannot use arithmetic ops to do time calculations -- very annoying

Hmmm...  **very** annoying????

>     Must cons to generate a time; not low overhead.

This is bogus.  Many fixnum representations only cover the range -2^29
.. 2^29-1 so the number of seconds since the epoch is already a
bignum, and nanoseconds also overflow into bignum territory.  Using a
flonum (counting the number of microseconds since the epoch) is
probably faster and more space efficient.  Encapsulating this flonum
in an abstract datatype is good so that the implementation dependent
choice of tick (the microsecond today, the picosecond in 10 years
(when we have 128 bit flonums!!!)) is hidden from the user.

Moreover, getting the current time from the OS can be quite expensive
(I measured about 5 microseconds on Linux RH 6.1 with a 600MHz Athlon,
which is the equivalent of 3000 machine cycles!!!) so you will not
notice the overhead of allocation.