ENH: TimeDeltaIndex and corresponding scalar #3009
Labels
Dtype Conversions
Unexpected or buggy dtype conversions
Enhancement
Indexing
Related to indexing on series/frames, not to indexes themselves
Refactor
Internal refactoring of code
Timedelta
Timedelta data type
Milestone
(e.g. dt + dt, only dt - dt?) BUG/API: Fix operating with timedelta64/pd.offsets on rhs of a datelike series/index #4534
Timestamp (Timedelta?), direct wrapper might work, ENH: create Timedelta scalar / TimedeltaIndex #8184
that forwards methods, internally repr as timedelta64 (or view?) as array
see Weird Datetime Behaviour #3002 and ENH: support min/max on timedelta64[ns] Series #2990, ENH: timedelta should write correctly to csv #4378
read_csv to have aparse_timedelta
to automatically apply the dtype, see API: add parse_timedelta kw for read_csv #4650, ENH: GH3371 support timedelta fillna #4684, moved to ENH: read_csv to have a parse_timedelta kw to automatically parse into timedelta64 #8185The text was updated successfully, but these errors were encountered:
This would be totally awesome, especially for any kind of experimental data.
there is already quite a lot of support, see the time delta section (in time series part of docs)
this is just an extension to make it easier to do some things
eg the index is works but its am Int64Index, so a bit non-intuitive
ha! didn't realize i had seen this already
For reference (as #7640) was not the appropriate place to share, here's a hacked implementation of datetime --> timeinterval.
http://nbviewer.ipython.org/github/hugadams/pyuvvis/blob/master/examples/Notebooks/intervals.ipynb
I'd imagine the TimeDeltaIndex should supplant the need for such an API entirely.
Almost have this working.
I think I need something better for the repr, because unlike other formats, commas CAN be in a single element, so it gets confusing.
any thoughts
@jorisvandenbossche @cpcloud @hayd @TomAugspurger
cc @shoyer
@jreback Sweet! Is there a
Timedelta
scalar or are you just reusingnp.timedelta64
? Is there some support for missing values likeNaT
? (Maybe you have a PR or branch which answers these questions?)@shoyer just created a
Timedelta
scalar (pretty much like a Period, but no freq), just a .value really. I need it mainly to box (otherwise you get sillynp.timedelta64
when displaying which is ugly).NaT
should work as well.not really any tests yet though :)
https://github.com/jreback/pandas/tree/tdi
API issue:
should a
Timedelta
scalar be moretimedelta
like ornp.timedelta64
like?mainly this is for the constructor. should it be as close to
timedelta
as possible so that they are 'effectively' interchangeable (but withTimedelta
improving on the oddiietes), much likeTimestamp
does?If you can get back from the string to the timedelta, then maybe stringify the repr to remove comma ambiguity:
+1 This looks great!
I assume that the you will be able to query using any string that can be handled by
pd.to_timedelta
? e.g.,s.loc['1 day']
?RE:
timedelta
like ornp.timedelta64
like: I thinkTimestamp
sets a clear precedent (even though I'm not sure that was the right decision -- there is something to be said for being similar to a numpy scalar, whichTimestamp
is not) so I would makeTimedelta
moretimedelta
like.yep that's pretty easy
a bit trickier (but not a lot) is partial string indexing
eg s.loc['1 day':]
is effectively >=1 day and < 2 days
why wouldn't that be ">= 1 day"?
For the repr, other option is to use
;
to seperate? But maybe quoting is better (;
is not used for anything else)@jreback How would both look like (what would be the differences) if Timedelta would more be like datetime.timedelta or np.timedelta64?
And would a timedelta64 series element also return this? (like you now also get Timestamps from a datetime64 series)?
So I created
Timedelta
as an extension type almost exactly likeTimestamp
(it has a c-extension and a shadow python class). This makes it a sub-class oftimedelta
which is nice (and also has a numpy-like value which makes it fast, though like Timestamp its not actually stored in an Index or Series, rather the underlying data is (which is how it is currently)only API change in this entire thing really is that
to_timedelta
will now return aTimedeltaIndex
rather than aSeries
by default (which makes it consisten withto_datetime
as well).Still need more tests / integration.
PR is now #8184, further comments can go there
tz_localize
andtz_convert
to Series.dt methods #8187