From rtvd at mail.ru Sat Sep 22 17:15:43 2007 From: rtvd at mail.ru (Denys Rtveliashvili) Date: Sat, 22 Sep 2007 21:15:43 +0400 Subject: [local-time-devel] microseconds/nanoseconds in timestamps Message-ID: <46F54DBF.5060602@mail.ru> Hi, I am looking for a way to find out time with a high precision, ideally up to microseconds. As far as I understand, the standard Common Lisp library does not allow to do that. However local-time library's API does provide that kind of functionality in its API. So I tried my luck. Unfortunately, it looks like (local-time-msec (now)) always returns zero. The (now) does not populate the msec field so there is no way to get the time stamp with the required resolution. As for formatting the time, I see that there is a library cl-i10n (http://common-lisp.net/project/cl-l10n/) which provides among other things time formatting functionality. Unfortunately, even though they declare support for printing out nanoseconds component of time stamp, in practice it is always shown as 000000000. I am wondering if you find these ideas useful: 1. use implementation-specific features to get high-precision time when possible 2. change the library so that nanoseconds are used instead of microseconds (this will give more space for maneuvering in the future and will not be difficult at all) Regards, Denys Rtveliashvili From attila.lendvai at gmail.com Sat Sep 22 22:25:04 2007 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Sun, 23 Sep 2007 00:25:04 +0200 Subject: [local-time-devel] microseconds/nanoseconds in timestamps In-Reply-To: <46F54DBF.5060602@mail.ru> References: <46F54DBF.5060602@mail.ru> Message-ID: hi! > As for formatting the time, I see that there is a library cl-i10n > (http://common-lisp.net/project/cl-l10n/) which provides among other > things time formatting functionality. Unfortunately, even though they > declare support for printing out nanoseconds component of time stamp, in > practice it is always shown as 000000000. it's been on my todo for a long time to add a local-time integration file to l10n, preferably using asdf-system-connections (see defclass-star's .asd for examples). but unfortunately there are too many other things before this... so i'm all open for such work/fixes. > I am wondering if you find these ideas useful: > 1. use implementation-specific features to get high-precision time when > possible it's already done on sbcl using sb-unix:unix-gettimeofday (although it only has usec precision). > 2. change the library so that nanoseconds are used instead of > microseconds (this will give more space for maneuvering in the future > and will not be difficult at all) i personally wouldn't mind that if it doesn't mean bignum arithmetic at some part of the code, but it would be good to hear Daniel's opinion in this, too. -- attila From rtvd at mail.ru Sun Sep 23 16:00:03 2007 From: rtvd at mail.ru (Denys Rtveliashvili) Date: Sun, 23 Sep 2007 20:00:03 +0400 Subject: [local-time-devel] proper way to "travel in time"(?) Message-ID: <46F68D83.6010405@mail.ru> Hi, I've got one more question: is there any way to find shift the local-time by minute/hour/day/month/year back and forth so that the number of days in month and in year are taken into account automatically? I see there is a function named "local-time-sum" but I do not think it will do what I need. For instance, its results will be weird if I try to shift the time stamp by one month. Regards, Denys Rtveliashvili From attila.lendvai at gmail.com Mon Sep 24 09:07:44 2007 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Mon, 24 Sep 2007 11:07:44 +0200 Subject: [local-time-devel] proper way to "travel in time"(?) In-Reply-To: <46F68D83.6010405@mail.ru> References: <46F68D83.6010405@mail.ru> Message-ID: > I've got one more question: is there any way to find shift the > local-time by minute/hour/day/month/year back and forth so that the > number of days in month and in year are taken into account > automatically? I see there is a function named "local-time-sum" but I do > not think it will do what I need. For instance, its results will be > weird if I try to shift the time stamp by one month. i think you should use decode/encode-local-time for this: (encode-local-time 0 0 0 0 40 01 2000) => @2000-02-09T00:00:00+01:00 so, overflowing on the values is handled gracefully. this behaviour as an API is arguable, but this is how it works now. maybe we should eventually add a keyword arg to encode-local-time that tells whether to allow it or not... there's also local-time-adjust-days, it's basically what you need for days. the rest is implementable using encode/decode-local-time. -- attila From rtvd at mail.ru Tue Sep 25 18:08:49 2007 From: rtvd at mail.ru (Denys Rtveliashvili) Date: Tue, 25 Sep 2007 22:08:49 +0400 Subject: [local-time-devel] proper way to "travel in time"(?) In-Reply-To: References: <46F68D83.6010405@mail.ru> Message-ID: <46F94EB1.1000209@mail.ru> Hi Attila, I am afraid, this method will not work as one might expect in some situations. In case there is a shift in month or a year resulting in an invalid day of month, there will be an overflow. For instance, a shift by one month back from the 31st of October, 2007 will result in the 1st of October, 2007. So, the month will not actually change. Instead, it would be more natural to get 30th of September, 2007 as a result. I have made a small investigation in this matter and found that Java's GregorianCalendar class performs such kind of corrections and they are well documented. I am going to try doing something like that myself and if the result is nice I will send it to this maillist. Regards, Denys Rtveliashvili >> I've got one more question: is there any way to find shift the >> local-time by minute/hour/day/month/year back and forth so that the >> number of days in month and in year are taken into account >> automatically? I see there is a function named "local-time-sum" but I do >> not think it will do what I need. For instance, its results will be >> weird if I try to shift the time stamp by one month. >> > > i think you should use decode/encode-local-time for this: > > (encode-local-time 0 0 0 0 40 01 2000) => @2000-02-09T00:00:00+01:00 > > so, overflowing on the values is handled gracefully. this behaviour as > an API is arguable, but this is how it works now. maybe we should > eventually add a keyword arg to encode-local-time that tells whether > to allow it or not... > > there's also local-time-adjust-days, it's basically what you need for > days. the rest is implementable using encode/decode-local-time. > > From attila.lendvai at gmail.com Tue Sep 25 19:33:40 2007 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Tue, 25 Sep 2007 21:33:40 +0200 Subject: [local-time-devel] proper way to "travel in time"(?) In-Reply-To: <46F94EB1.1000209@mail.ru> References: <46F68D83.6010405@mail.ru> <46F94EB1.1000209@mail.ru> Message-ID: > I am going to try doing something like that myself and if the result is > nice I will send it to this maillist. sounds good, looking forward to it! -- attila -------------- next part -------------- An HTML attachment was scrubbed... URL: