mxDateTime history (Re: mktime, how to handle dates before 01-01-1970 ?)

[M.-A. Lemburg]

John Yeung wrote:
> On Oct 6, 4:10 pm, Stef Mientki <stef.mien... at gmail.com> wrote:
>>
>> thanks guys,
>> mx works a bit better  ....
> 
> Another popular Python date library is dateutil:
> 
>   http://labix.org/python-dateutil
> 
> It gives a certain amount of credit to mxDateTime (praising it but not
> being very clear how they are related; there is some mention of "using
> the specification" of mxDateTime).

History goes a bit like this:

mxDateTime was the first Python library to implement native
date/time types for Python. I started the project in 1997.

Back then I had a good look around at the various date/time
libs and then decided to take a little more academic approach
to the whole thing. The result was that you only need two basic
types in mxDateTime: the DateTime object, which refers to a point
in time, and the DateTimeDelta object, which allows measuring
the time span between two such points. Note the absence of
a Date object. These would be date/time range objects since they
apply to the timespan of a full day with a time reference point
at midnight. I decided to leave such ranges for a later stage
in development - and have so far, never needed them :-)

A bit later in 1998, I also added the RelativeDateTime object,
which allows doing date/time calculations based on relative terms,
e.g. x minus one year (which could mean 356 or 366 days
depending on the year), first of next month (which could
mean anything from 1-31 days), last of next month, Tuesday
in 3 weeks, last Monday next month, etc.

And again a bit later in 2000, I added the RelativeDateTimeDiff
object which works a bit like an age function in that it tries to
determine the RelativeDateTime value which has to be applied
to a DateTime object in order to reach another one, say
from your birthday to today. The result reads is more user-
friendly than a bare DateTimeDelta, e.g. you get 40 years,
6 months, 3 days instead of 14796 days.

In 2002 Zope Corp initiated the development of the datetime
module, which borrowed a lot of design and API ideas from
mxDateTime.

However, it did not provide a date/time string parser and also
misses out on lots of the other good stuff you can find in
mxDateTime.

Gustavo Niemeyer started to work on a date/time parser based
on the datetime module - that's the python-dateutil library.
He also added a relative date/time object which was one of the
bits Zope Corp left out in the datetime module from mxDateTime
and added some other things that are not currently part of
mxDateTime: recurring events and time zones.

mxDateTime continues to be actively developed - mostly driven
by eGenix' own needs and experience we find in projects. Whenever
we need something new, we can just add it to mxDateTime and since
its release cycle is not bound to Python's, such enhancement
are more readily available to others as well.

Overall, my impression is that the datetime module was designed
on the drawing board without actually touching real life
usage scenarios.

We've just done a project that used the datetime module for
date/time related things instead of mxDateTime and
found that while the implementation is similar to mxDateTime
(naturally, see above), many useful features you find in mxDateTime
are not available on the datetime objects.

For future releases, we'll make the interaction between the
two implementations more user friendly, e.g. it should be
possible to pass a datetime object to mx.DateTime.DateTimeFrom()
and call a method on DateTime objects to get a datetime
module object with the same values.

> I would say mxDateTime and dateutil are the two heavyweights in this
> arena.  As you would expect, they have a lot of overlapping
> functionality and which one is used is often just a matter of taste,
> or whichever one you happened to find first.
> 
> One thing that dateutil provides that mxDateTime doesn't is support
> for "lay person" month operations.  That is, as far as I can tell,
> mxDateTime tries not to dirty itself with the messy business of month
> arithmetic, whereas dateutil rolls up its sleeves and takes an honest
> stab at it.  If you are writing a calendar/appointment application, or
> other end-user-facing program, I would expect dateutil to be a little
> more helpful.

Month arithmetic is a bit of a mess, since it's not clear how
to map e.g. Jan 31 + one month.

mxDateTime does support month arithmetic via the RelativeDateTime
object, but I'm not all that happy with the solution to the above
problem. The alternatives are basically deciding between loosing
data or raising an exception - both aren't really all that nice.

Perhaps I'll just add a parameter to allow customization of the
behavior depending on application needs.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Oct 09 2009)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/