From marijnh at gmail.com Thu Feb 15 12:57:38 2007 From: marijnh at gmail.com (Marijn Haverbeke) Date: Thu, 15 Feb 2007 13:57:38 +0100 Subject: [local-time-devel] A new release & possible extensions Message-ID: Hello list, A while ago I ended up implementing a simple date/time library to supplement a database interface library (http://common-lisp.net/project/postmodern). I considered using local-time, but didn't for two reasons: - Lack of support for non-Unix platforms - No separate types for dates and timestamps, no interval type Attila told me that he has pushed patches that fix the first problem. Would it be considered a good idea if I made a patch that adds a separate date type (for more straightforward mapping between lisp and SQL types), and an interval type? I saw something about intervals in the TODO file. Here is how my simple-date lib, and Postgresql, approach intervals: They consist of a millisecond part and a month part. When creating one, the user can specify an amount milliseconds, seconds, minutes, hours, days, weeks, months, and years. All of these except the last two are incorporated in the millisecond part, and the last two in the month part. Intervals can be added and subtracted from dates and timestamps, first the millisecond part is added, and then it shifts the month part, making sure that it doesn't end up on something like feb 30th. If local-time takes leap seconds into consideration this would be more involved though (does it?). So, if you like these suggestions, and once I get around to implementing them, local-time would be a good replacement for my own timezone-ignorant library in Postmodern. At that point it would be nice if a new asdf-installable release was made, so that users of my lib do not have to dig in repositories to fetch dependencies, but I suppose that wouldn't be too hard to arrange. Regards, Marijn From attila.lendvai at gmail.com Sun Feb 18 16:15:05 2007 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Sun, 18 Feb 2007 17:15:05 +0100 Subject: [local-time-devel] A new release & possible extensions In-Reply-To: References: Message-ID: > - Lack of support for non-Unix platforms > - No separate types for dates and timestamps, no interval type i think we are dealing with these concepts (with an "uneducated guessing" warning): 1) a point in time (this is a local-time struct currently) 2) a date (i use local-time structs with UTC zone and minimized time part) 3) intervals (two local-time objects, maybe a simple cons cell? probably a struct or a CLOS class would serve better) 4) duration (elapsed units of time; only secs/usecs or support for all calendar units?) i'm not sure about separate date objects. the reason is that a local-time in the UTC zone and minimized time part works fine with all the local-time specific arithmethic operators. if we introduced a separate date object then it would introduce a lot more code unless there's an easy way to capture the shared logic. otoh, i can see that sometimes it would be useful to have a standalone object to be able to dispatch on it. but then i would still keep a low-level struct (what local-time is currently), and introduce CLOS objects that use the low-level struct for implementing the higher level concepts (if we decided to introduce them). but enough of this rumbling, i should definately read more on the subject before making deeper comments. -- - attila "- The truth is that I've been too considerate, and so became unintentionally cruel... - I understand. - No, you don't understand! We don't speak the same language!" (Ingmar Bergman - Smultronst?llet) From dlowe at bitmuse.com Sat Feb 24 19:35:41 2007 From: dlowe at bitmuse.com (Daniel Lowe) Date: Sat, 24 Feb 2007 13:35:41 -0600 Subject: [local-time-devel] A new release & possible extensions Message-ID: <45E0938D.4000004@bitmuse.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marijn Haverbeke wrote: > > Hello list, > > > > A while ago I ended up implementing a simple date/time library to > > supplement a database interface library > > (http://common-lisp.net/project/postmodern). I considered using > > local-time, but didn't for two reasons: > > > > - Lack of support for non-Unix platforms > > - No separate types for dates and timestamps, no interval type > > Attila told me that he has pushed patches that fix the first problem. Yes, we're now including the standard unix timezone files as part of the distribution. (speaking of which: we probably need to update them since the U.S. Congress decided to change daylight savings time. ugh.) It's through these that local-time calculates leap days and seconds. I would love to include interval support. Given that the local-time library is based on Naggum's paper, though, some thought has to be given to the points he brought up. Mainly, there is no interval of time that is a stable number of sub-intervals except weeks (which always equal seven days) and years (which always equal 12 months). We can store intervals fine, but with leap days, and leap seconds, doing arithmetic operations on them is problematic. There are also the familiar annoying corner cases - what's a month after Feb 29th? Whatever the solution, it needs to be as predictable and well-documented as possible. My own idea for the structuring was this: (defclass local-time () (day sec usec)) (defclass duration () (year month day hour min sec usec)) (defclass interval (local-time duration) ()) The local-time structure stays as is: having a separate date class is a semantic division, not a functional one. If you have to have a date class for database serialization, you can subclass it and ignore the time part completely. The duration structure has a field for each part, keeping them separate because the parts aren't truly translatable into each other. Duration-time arithmetic would be done by attempting to keep lower-order date parts intact, so incrementing the year would only modify the year part. Any invalid dates would be rounded to the later valid date. 2004-02-29 + 1 year would be 2005-03-01, not 2005-02-28. It would work the same for months: 2004-02-29 + 1 month would be 2004-03-29. Arithmetic overflow would proceed from usec to year. Please let me know what you think. > > So, if you like these suggestions, and once I get around to > > implementing them, local-time would be a good replacement for my own > > timezone-ignorant library in Postmodern. At that point it would be > > nice if a new asdf-installable release was made, so that users of my > > lib do not have to dig in repositories to fetch dependencies, but I > > suppose that wouldn't be too hard to arrange. If we add interval support, that would certainly be worthy of a new asdf-installable release. : Daniel : -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF4JONF+/5ikZycMQRAuYjAJ9/pXWc30xcTwdqwQiC6iIPU5cYIgCfbUy6 RpW+iQnZnAjcKoUJJd7ZUGA= =luQ7 -----END PGP SIGNATURE-----