[Numpy-discussion] datetime update

[David Cournapeau]

On Tue, Nov 24, 2009 at 8:42 AM, Travis Oliphant <oliphant at enthought.com> wrote:
>
> I've made a few changes to datetime today and spent some time looking over
> what is there and what remains to be implemented.
> Basically, the biggest thing left to do is to implement the low-level
> casting functions to and from datetime types and other numpy types.  In
> addition, the ufuncs need some auditing to make sure the right thing is
> being done when mixing different units.  After that, lots and lots of
> additional tests need to be written.      Once that is done, then most of
> the features should be available, but I suspect a few lingering issues might
> crop up and require fixing or fleshing out as well.
> I was hoping that someone would be able to contribute more tests for
> datetime.    I will spend some time on the casting functions over the next
> few weeks and write a few tests.
> I fixed a problem today with the fact that PyArray_DescrFromScalar was not
> returning a data-type object with the correct frequency information stored
> when given a datetime64 or timedelta64 scalar (it was ignoring the date-time
> metadata on the scalar).   This fixed a problem with the printing so that
> now a = arange(10).view('M8[Y]') shows something reasonable.
> I also removed numpy.datetime and numpy.timedelta from the namespace
> (replaced them with numpy.datetime_ and numpy.timedelta_).   These were just
> short-hand for numpy.datetime64 and numpy.timedelta64 respectively.
> Avoiding the collision seemed like a good idea.
> Right now, what works is "viewing" arrays as datetime data-types and getting
> and setting date-time arrays using datetime objects.   I would like to
> improve it so that setting with strings, integers, and other Python objects
> works as well.

Thanks for the update, Travis, that's really helpful.

>   Also, adding simple integers works, but
> Dave C suggested removing the new C-API calls which sounds like a good idea
> to me for 1.4.0.

So that's clear for everyone, this just means that the functions will
not be exported (i.e. 3rd party C extensions cannot use those
functions), the code will still be there.

The rationale is that if the functions need to be changed for any
reason, it will break backward compatibility for *any* package using
numpy C api (scipy, matplotlib, etc...). By not exporting those
functions, we allow ourselves to change them in the 1.5.0 timeframe,
at the much cheaper cost of preventing 3rd party extensions to use
datetime stuff from C for 1.4.0 (but it can still be used from
python).

David