Heh. Looks like the correct diagnosis, I'll let Mark review the fix.

It looks great, thanks for the patch! Would you be willing to add tests for/verify that Python's datetime.date and datetime.datetime objects work in this context as well?

Oh alright then :-) Will add something to the commit soon...

Hi

Can I just check what you mean by "datetime.datetime objects work in this context"? Do we want np.array to always convert datetime.datetime to np.datetime64?

This would mean that np.array([datetime.date(2000, 1, 1)])[0].year will now break, as we don't have a datetime.date object any more; we have a np.datetime64.

So I'm not sure what to do. The "aggressive" conversion to datetime64 fits better with other numpy types, but it will mean more breakages of existing code. Perhaps I misunderstood your intentions here.

Cheers

Ben

That is what I was thinking, but I definitely see your point about how it breaks compatibility. I've been toying with ideas about how to expose the datetime as fields, but there doesn't seem to be a reasonable way to do it that would match Python's datetime.

At the very least, the behavior with regard to datetime.date and datetime.datetime should be well-defined, so we still need tests that confirm the current behavior if we're leaving it as is.

OK, I've added the test. I didn't create a branch (doh) so I'm having trouble attaching another commit to this request. Will submit a new request.

To get your new commits to show up, you have to push your branch to origin. In this case, you would push master to origin, but having a topic branch is better, for sure.

I've merged the two patches you made, thanks!