[local-time-devel] Questions & minor Clozure CL/OpenMCL issue

[Arjan Wekking]

On 11 jul 2008, at 16:30, Daniel Lowe wrote:

> Arjan Wekking wrote:
>> 1. What's up with local-time development lately? There appears to be
>> little activity since March.
>
> Hi, Arjan.  There's actually been quite a bit, but it's been on the  
> 1.0 branch.
> We've been trying to get the code to the point where we're  
> comfortable freezing
> the API.  I think we're almost to that point - we'll make an  
> announcement when
> we release.

Ah yes, I totally did not see the 1.0 branch anywhere. Is discussion  
going on somewhere else or is there just person-to-person mails going  
around between developers?

>> 2. The TODO mentions intervals; what plans are there to add them  
>> and how
>> will they be used? Have you seen the way Joda-Time defines intervals,
>> durations and periods? What *are* the intervals mentioned in the TODO
>> anyway?
>
> This is more a question of representing duration, and periods of  
> time (timestamp
> + duration).  There's more of a pragmatic question as to whether or  
> not to
> support a representation of duration which includes multiple units  
> of time.

That's what I like about Joda-Time's approach; a clear separation  
between intervals (two time-stamps), durations (a duration of time in  
milliseconds) and periods (in terms of 'human' fields; 2 days and 4  
hours).

My experience has been that this seems to be a very clean and correct  
way to handle date/time calculations and also maps nicely to ISO 8601  
durations/periods and intervals which are commonly used in databases  
and XML as well.

But, I'll have to take a better look at what local-time offers first ;)

>> 3. Clozure CL does not like #.+some-constant+ and/or #.(-
>> +some-other-constant+) since it apparently has not yet defined  
>> constants
>> at read time (makes sense, perhaps). Removing #. in these cases  
>> works of
>> course, but I'm wondering why read-time evaluation was used and  
>> whether
>> I'm missing something here (they *are* constants, after all)?
>
> In all likelihood, they started as defparameters and were changed to  
> constants
> later.  It behaves fine in sbcl, but should certainly be changed.

I have recorded a patch in my local repo of local-time-1.0 to make  
things compile and work on Clozure CL. I've also made local-time:now  
work with nanoseconds in Clozure CL (tested) and CMUCL (untested)  
using their ways of accessing gettimeofday. Are you interested in  
these and, if so, where should I send these patches?

>> 4. Is (my) help welcome? If so, how can we contribute? What is the
>> preferred way to offer and discuss patches like my (possibly wrong)
>> Clozure CL fix?
>
> The most useful thing you could do would be to check out the 1.0  
> branch and
> offer comments.  You can find it at
> http://common-lisp.net/projects/local-time/darcs/local-time-1.0

Comments will come soon now that we are going to actively use it. So  
far, things are looking fine though...

Regards,
-Arjan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3405 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/local-time-devel/attachments/20080722/f44533c3/attachment.bin>