[local-time-devel] one more patch with two new functions

[Attila Lendvai]

> Also, regarding the idea to use nanoseconds instead of microseconds.. I
> think it has sense to do it as the maximal value of nanoseconds would be
> 10^9 which is smaller than 2^30 and thus manipulations with it should
> not cause bignum arithmetics. I am planning to make this change as well.


this sounds good to me.


> One more idea: when adjusted-local-time is included, perhaps it has
> sense to move local-time-adjust-days's functionality into it. It would
> be more convenient to have the single function to get a modified time no
> matter what field has to be changed, won't it?


yep, we can just drop local-time-adjust-days in favour of a function
that can adjust any part of a local-time.


> Ideally, if we have a possibility to read the current timestamp with the
> precision up to nanoseconds we would benefit from it. However, the
> situation regarding the acquiring high precision time stamps looks not
> very good right now. I have made a little investigation and it looks
> like only SBCL provides such functionality (and I am glad that my
> home-grown logging system can benefit from it). But as far as I see
> neither CLISP nor Lispworks support this feature. And I guess AllegroCL
> does not support that as well. Perhaps it will have sense to create an
> optional native library to add this feature at least for UNIX platforms
> no matter which flavor of LISP is used.


i think we should push the changes so that it works on sbcl and falls
back to whatever precision is available on other lisps. then later
users of other lisps can add their own version.


> One more thing: I have tried to add (declaim (optimize speed)) at the
> top of local-time.lisp. SBCL shows a large amount of warning that it is
> unable to optimize the code as it is not clear what are types of the
> arguments. I think it might have sense to make sure that fields of
> local-time have strict limits on values and then coerce function
> arguments to integers (possibly with ranges), whenever it is possible.

i wouldn't do that. i usually add the optimize declares to specific
functions only that are known to be hot-spots (first to the obvious
ones and then to the ones that show up while profiling).

then you won't get tons of compiler notes and things remain more
debuggable if something goes wrong.

i've pulled your patch for me, after some test period i'll push stuff
to the official.

-- 
 attila

ps: darcs doesn't let you send patches that depend (line collision) on
other patches unless you send the depended on patches, too. if you
want to keep patches independent, you need to be careful what to
record in a patch. it's a good strategy to record separate patches
that do specific functionalities and record "housekeeping"-like
patches that change many places in the project, but does not alter
functionality much.