From mail at chaitanyagupta.com Sun Apr 5 16:36:18 2009 From: mail at chaitanyagupta.com (Chaitanya Gupta) Date: Sun, 05 Apr 2009 22:06:18 +0530 Subject: [local-time-devel] TIMESTAMP+ doesn't work correcly when adding months Message-ID: <49D8DE02.9030000@chaitanyagupta.com> Hi, There seems to be a bug in TIMESTAMP+ -- it doesn't work correctly while adding months. e.g. (local-time:timestamp+ (local-time:encode-timestamp 0 0 0 0 1 3 2009) 1 :month) => @2009-03-29T00:00:00.000000+05:30 I would have expected this to return @2009-04-01T00:00:00.000000+05:30 Cheers, Chaitanya -- http://chaitanyagupta.com/blog/ From attila.lendvai at gmail.com Wed Apr 8 07:43:16 2009 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Wed, 8 Apr 2009 09:43:16 +0200 Subject: [local-time-devel] TIMESTAMP+ doesn't work correcly when adding months In-Reply-To: <49D8DE02.9030000@chaitanyagupta.com> References: <49D8DE02.9030000@chaitanyagupta.com> Message-ID: > There seems to be a bug in TIMESTAMP+ -- it doesn't work correctly while > adding months. e.g. > > (local-time:timestamp+ (local-time:encode-timestamp 0 0 0 0 1 3 2009) 1 > :month) > => @2009-03-29T00:00:00.000000+05:30 try this (notice the :offset 0): (local-time:timestamp+ (local-time:encode-timestamp 0 0 0 0 1 3 2009 :offset 0) 1 :month) => @2009-04-01T02:00:00.000000+02:00 the problem is that there's no proper support for dates yet, and a timestamp will never behave intentional when it's used as a date. it's on our (cl-dwim guys) TODO, and Daniel (l-t 's author) even wrote up an implementation plan. i think the general conclusion is that the Java lib called Joda has the right ideas about dates and partial timestamps. but i'm personally lacking both the time and a clear vision on how it should work (although it's related, because if one knows how it should work then typing it up shouldn't be more than a day, including tests). any volunteers? :) -- attila From dlowe at bitmuse.com Thu Apr 16 20:15:57 2009 From: dlowe at bitmuse.com (Daniel Lowe) Date: Thu, 16 Apr 2009 16:15:57 -0400 Subject: [local-time-devel] Bugfix: nsec overflows fixnum on 32-bit archs In-Reply-To: <50b7e5180903131308m414a3953ic83c3cbc05d612d5@mail.gmail.com> References: <50b7e5180903131308m414a3953ic83c3cbc05d612d5@mail.gmail.com> Message-ID: <49E791FD.9000206@bitmuse.com> Maciej Katafiasz wrote: > Hi, > > here's a bugfix for one issue that hit me on 32-bit SBCL. Since > MOST-POSITIVE-FIXNUM is less than 10^9, nanoseconds can overflow a > fixnum. This means that WITH-DECODED-TIMESTAMP (and by extension, > ADJUST-TIMESTAMP) would fail randomly. The patch conditionalises the > type declaration on whether a fixnum can hold all the required bits. Thanks for bringing the bug to our attention. Unfortunately, you can't use declarations that way in most implementations, but we can fix it anyway. Sorry for the problems. : Daniel : From mathrick at gmail.com Fri Apr 17 13:31:40 2009 From: mathrick at gmail.com (Maciej Katafiasz) Date: Fri, 17 Apr 2009 13:31:40 -0000 Subject: [local-time-devel] Confusing behaviour of ADJUST-TIMESTAMP Message-ID: <50b7e5180904170631x11628d04n39406f214bb262df@mail.gmail.com> Hi, I completely fail to understand how ADJUST-TIMESTAMP is supposed to behave. What I observe is, at best, counterintuitive: KABINETT-TEST> (today) ;; It's 17th today @2009-04-17T00:00:00.000000+02:00 KABINETT-TEST> (adjust-timestamp (today) (set :hour to 11)) ;; But here it somehow jumps back to 16th, and the hour is set to 13:00 +0200 @2009-04-16T13:00:00.000000+02:00 KABINETT-TEST> (adjust-timestamp (today) (offset :hour by 11)) ;; Here it's still 17th, and the hour is 11:00 +0200 @2009-04-17T11:00:00.000000+02:00 The fact that the date changes when I set the hour is very surprising, as is the fact that it sometimes takes the timezone into account, and sometimes doesn't. Is that how it's supposed to work? If so, a proper and detailed explanation (possibly a link to the relevant section of Naggum's paper; it's very hard to infer what exactly the desired behaviour is from reading the whole paper without any sort of connection to the relevant implementation parts) is in order. If not, consider it a bug report. Cheers, Maciej