[local-time-devel] A new release & possible extensions

[Daniel Lowe]

-----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-----