ENH add time to DatetimeIndex

[hayd]

This adds a convenience property (.time) to DatetimeIndex, implementation is not very clever, but it means you can extract an array of time objects similar to .hour et al.

Thoughts?

[jreback]

can you put up a usecase?

[hayd]

In this SO question someone is trying to plot by time of the day, and this seems like a reasonable thing to do. I think I have seen quite a few similar cases, and have been confused that it doesn't exist before.

week/weekofyear/dayhour/minute/nanosecond work in this way...

Also I think if time is available for Timestamp it would be consistent to have it in DatetimeIndex... Saying that, there are a few others also not in DatetimeIndex but in Timestamp, perhaps they should be available as well? (or maybe it's just strange that the above things work in this way...). Hmmm.

[jreback]

I saw that question....but sort of asking whether it might be worthwhile to give back a Timestamp like object here (e.g. a different sub-class, rather than a datetime), or is this overkillish...?

[hayd]

It's a fair point, the other attributes return integer arrays, this would be an object and the implementation won't be efficient on big DatetimeIndexes.

I don't really think it's a problem in the use cases I was be thinking of (e.g. plotting), and you can groupby (or something...) to do "time of day" analysis... (?)

At the moment when you subtract a timestamp from another you get a datetime.timedelta... The delta would be an easier thing to do something like this with, since probably modulo "nanoseconds in a day" is hopelessly naive to get the time... (it probably is overkillage anyways.)

[jreback]

actually I was sort of thinking of timedeltas
in 0.11 we r fully supporting timedelta64[ns] types
not yet a scalar that wraps timedelta64 nor a dedicated index (it's a int64 for now)
just search for timedeltas on issues

in any event I am not that is what u r after here

[jreback]

see #3009 for example

[wesm]

Cherry-picked. Thanks