From arjan at streamtech.nl Thu Jul 10 15:44:18 2008 From: arjan at streamtech.nl (Arjan Wekking) Date: Thu, 10 Jul 2008 17:44:18 +0200 Subject: [local-time-devel] Questions & minor Clozure CL/OpenMCL issue Message-ID: Hello, While looking around for a good and hopefully actively developed CL date/time library for our projects I kind of settled on local-time for now. I do have a few questions regarding development and a minor issue I'm having with Clozure CL and local-time: 1. What's up with local-time development lately? There appears to be little activity since March. 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? 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)? 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? I hope I do not appear too rude or anything by posing a list of numbered questions, just trying to figure things out and hoping there are some people active on this mailing list ;) Thanks, -Arjan -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3405 bytes Desc: not available URL: From dlowe at bitmuse.com Fri Jul 11 14:30:46 2008 From: dlowe at bitmuse.com (Daniel Lowe) Date: Fri, 11 Jul 2008 10:30:46 -0400 Subject: [local-time-devel] Questions & minor Clozure CL/OpenMCL issue In-Reply-To: References: Message-ID: <48776E96.5070007@bitmuse.com> 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. > 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. > 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. > 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 Thanks for your interest. : Daniel : From arjan at streamtech.nl Tue Jul 22 13:44:23 2008 From: arjan at streamtech.nl (Arjan Wekking) Date: Tue, 22 Jul 2008 15:44:23 +0200 Subject: [local-time-devel] Questions & minor Clozure CL/OpenMCL issue In-Reply-To: <48776E96.5070007@bitmuse.com> References: <48776E96.5070007@bitmuse.com> Message-ID: <50E5B2EC-BF50-4ACF-B01D-C9C5B2D6A844@streamtech.nl> 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: From dlowe at bitmuse.com Tue Jul 22 13:48:52 2008 From: dlowe at bitmuse.com (Daniel Lowe) Date: Tue, 22 Jul 2008 09:48:52 -0400 Subject: [local-time-devel] Questions & minor Clozure CL/OpenMCL issue In-Reply-To: <50E5B2EC-BF50-4ACF-B01D-C9C5B2D6A844@streamtech.nl> References: <48776E96.5070007@bitmuse.com> <50E5B2EC-BF50-4ACF-B01D-C9C5B2D6A844@streamtech.nl> Message-ID: <4885E544.505@bitmuse.com> > 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? irc://irc.freenode.net/#lisp mostly. Attila Lendvai is, as far as I know, the only other real user of the library. > 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. I'll make sure to look at Joda-Time, then. It's always nice to have something that already works to use as a reference. > 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? Yes, we're interested. Please post them to the local-time-devel mailing list and we'll integrate it into the branch. Welcome aboard. :) : Daniel : From attila.lendvai at gmail.com Tue Jul 22 14:04:02 2008 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Tue, 22 Jul 2008 16:04:02 +0200 Subject: [local-time-devel] Questions & minor Clozure CL/OpenMCL issue In-Reply-To: <50E5B2EC-BF50-4ACF-B01D-C9C5B2D6A844@streamtech.nl> References: <48776E96.5070007@bitmuse.com> <50E5B2EC-BF50-4ACF-B01D-C9C5B2D6A844@streamtech.nl> Message-ID: > 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. fwiw, it sounds reasonable to me. although i think we should measure duration in seconds, the base unit, and rely on lisp's number support... and yep, welcome on board! :) -- attila From arjan at streamtech.nl Tue Jul 22 15:25:33 2008 From: arjan at streamtech.nl (Arjan Wekking) Date: Tue, 22 Jul 2008 17:25:33 +0200 (CEST) Subject: [local-time-devel] darcs patch: Removed read-time evaluation of constants (and 2 more) Message-ID: <20080722152533.7060517F9B8@mail.streamtech.nl> Mon Jul 21 16:55:11 CEST 2008 Arjan Wekking * Removed read-time evaluation of constants Clozure CL generates read errors when encountering read-time evaluation of constants such as '(integer 0 #.+seconds-per-day+) or #.+rotated-month-offsets-without-leap-day+ due to the constants not having been defined yet at read-time. I'm assuming most CL implementations will recognize these constants for what they are (constant) and will compile accordingly without these explicit reader macros. Tue Jul 22 12:21:26 CEST 2008 Arjan Wekking * Added %unix-gettimeofday with implementation for SBCL, CCL and CMUCL Maps to whatever the CL implementation has to access the UNIX gettimeofday(2) function. Returns NIL when the current implementation is not supported. Tue Jul 22 12:24:04 CEST 2008 Arjan Wekking * Made local-time:now portable by using %unix-gettimeofday This will add nanosecond timestamp support to local-time:now in Clozure CL (tested) and CMUCL (untested) besides the already existing SBCL support. To support any other CL implementations, simply add an implementation to %unix-gettimeofday. -------------- next part -------------- A non-text attachment was scrubbed... Name: removed-read_time-evaluation-of-constants.dpatch Type: text/x-darcs-patch Size: 14726 bytes Desc: A darcs patch for your repository! URL: From arjan at streamtech.nl Wed Jul 23 09:42:20 2008 From: arjan at streamtech.nl (Arjan Wekking) Date: Wed, 23 Jul 2008 11:42:20 +0200 Subject: [local-time-devel] Confused about encode-timestamp, offsets and timezones Message-ID: <4B1D01D0-EEDE-4005-A8E6-8D78947CB6AB@streamtech.nl> While making some functions to get the ISO 8601 week number of a timestamp I encountered the following issue with encode-timestamp that rather confuses me: CL-USER> (timestamp-day (universal-to-timestamp (encode-universal-time 0 0 0 4 1 2010))) 4 CL-USER> (timestamp-day (encode-timestamp 0 0 0 0 4 1 2010)) 3 CL-USER> (universal-to-timestamp (encode-universal-time 0 0 0 4 1 2010)) @2010-01-04T00:00:00.000000+01:00 CL-USER> (encode-timestamp 0 0 0 0 4 1 2010) @2010-01-03T23:00:00.000000+01:00 CL-USER> (universal-to-timestamp (encode-universal-time 0 0 0 22 07 2008)) @2008-07-22T00:00:00.000000+02:00 CL-USER> (encode-timestamp 0 0 0 0 22 07 2008) @2008-07-22T00:00:00.000000+02:00 It looks like encode-timestamp should be using (timezone *default- timezone*) instead of (offset (%get-default-offset)) to build a timestamp from the date/time fields since the offset computed by %get- default-offset is incorrect for dates outside the current daylight savings time state but correct for those within (see the second example above where the encoded date is in the same DST state). In general I think it would be better to not have the timezone 'offset' as a concept in the public API at all (also prevents confusion with offset in adjust-timestamp) and deal exclusively with timezones and the *default-timezone*. Perhaps I'm misunderstanding what encode-timestamp should be used for - I just wanted to create a timestamp for midnight Jan 4th of a given year (with the given or *default-timezone*) but currently I have to use universal-to-timestamp with encode-universal-time which is not very elegant. I'll pop by on IRC as well - it might make communication easier on stuff like this. -Arjan -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3405 bytes Desc: not available URL: From dlowe at bitmuse.com Wed Jul 23 12:55:20 2008 From: dlowe at bitmuse.com (Daniel Lowe) Date: Wed, 23 Jul 2008 08:55:20 -0400 Subject: [local-time-devel] Confused about encode-timestamp, offsets and timezones In-Reply-To: <4B1D01D0-EEDE-4005-A8E6-8D78947CB6AB@streamtech.nl> References: <4B1D01D0-EEDE-4005-A8E6-8D78947CB6AB@streamtech.nl> Message-ID: <48872A38.8040206@bitmuse.com> Arjan Wekking wrote: > In general I think it would be better to not have the timezone 'offset' > as a concept in the public API at all (also prevents confusion with > offset in adjust-timestamp) and deal exclusively with timezones and the > *default-timezone*. The encoding "offset" is deliberately there to make developers think about what they're really trying to do. We've been discussing entirely removing the default offset to that end, since it does entirely the wrong thing. We can't remove the concept though, because when you encode a time, there's a nasty piece of ambiguity. The problem is that a timezone can have different offsets from UTC at different times, and there's no precise way to implicitly derive an offset. Consider the case of 1am before and after daylight savings is in effect. The encode-universal-time manages this by having an _optional_ daylight savings indicator. All that does is subtract one from the offset, so it was deemed superfluous for the local-time library. One solution we might try is to expose an interface for querying the timezone for its subzones based on name. We could try having DWIM semantics - a date in January probably isn't going to run up against daylight savings. You could probably get away with using the offset for the date in UTC. However, one of the goals of the library is to explicitly expose the problems of time representation, and this is one of them. Incidentally, encode-universal-time has the same problem. The sbcl version tries to guess as well, it just guesses differently than %get-default-offset. : Daniel :