implement Timedelta mod, divmod, rmod, rdivmod, fix and test scalar methods #19365

jbrockmendel · 2018-01-24T03:32:19Z

Implemented mod, divmod, rmod, rdivmod for Timedelta, along with tests. In the process turned up a few bugs. Conditional probability that there are more bugs is pretty good.

fixed offsets.Tick // Timedelta, Timedelta // offsets.Tick
fixed Timedelta [+-] timedelta64 returning timedelta64 instead of Timedelta
fixed Timedelta [*/] int64 returning timedelta64 instead of Timedelta
closes #xxxx
tests added / passed
passes git diff upstream/master -u -- "*.py" | flake8 --diff
whatsnew entry

gfyoung · 2018-01-24T10:17:58Z

pandas/tests/scalar/test_timedelta.py

+        expected = np.array([9, 12], dtype='m8[m]').astype('m8[ns]')
+        tm.assert_numpy_array_equal(result, expected)
+
+        with pytest.raises(TypeError):


What's the error message?

add a comment on why this is prohibiited, any other ops not allowed?

gfyoung · 2018-01-24T10:18:16Z

pandas/tests/scalar/test_timedelta.py

@@ -128,6 +128,57 @@ def test_unary_ops(self):
        assert abs(-td) == td
        assert abs(-td) == Timedelta('10d')

+    def test_mul(self):


Reference your PR number under all of these added tests.

gfyoung · 2018-01-24T10:25:01Z

Conditional probability that there are more bugs is pretty good

There are always more bugs 😄

Also, you probably should add a whatsnew to address all of the things that you patched.

codecov · 2018-01-24T18:13:06Z

Codecov Report

Merging #19365 into master will decrease coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master   #19365      +/-   ##
==========================================
- Coverage   91.58%   91.58%   -0.01%     
==========================================
  Files         150      150              
  Lines       48862    48862              
==========================================
- Hits        44750    44748       -2     
- Misses       4112     4114       +2

Flag	Coverage Δ
#multiple	`89.95% <ø> (-0.01%)`	⬇️
#single	`41.75% <ø> (ø)`	⬆️

Impacted Files	Coverage Δ
pandas/util/testing.py	`83.64% <0%> (-0.21%)`	⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 44c822d...c22dc47. Read the comment docs.

jreback · 2018-01-25T01:13:49Z

pandas/tests/scalar/test_timedelta.py

@@ -138,6 +191,10 @@ def test_binary_ops_nat(self):
        assert (td // pd.NaT) is np.nan
        assert (td // np.timedelta64('NaT')) is np.nan

+        # GH#19365
+        assert td - np.timedelta64('NaT') is pd.NaT


test of the reverse?

jreback · 2018-01-25T01:13:59Z

pandas/tests/scalar/test_timedelta.py

+        assert isinstance(result, Timedelta)
+        assert result == Timedelta(days=20)
+
+        result = td + timedelta(days=9)


can you test for radd as well here

jreback · 2018-01-25T01:16:49Z

pandas/tests/scalar/test_timedelta.py

+        assert isinstance(result, Timedelta)
+        assert result == Timedelta(minutes=3, seconds=20)
+
+        # Invalid Others


can you make the error conditions separate and test all of the reverse failures e.g.
np.array([1, 2]) % td; I think pretty much every div/mod/divmod op should fail for the reverse (int/float op with td)

jreback · 2018-01-25T01:17:34Z

doc/source/whatsnew/v0.23.0.txt

@@ -419,6 +419,7 @@ Datetimelike
 - Bug in ``.astype()`` to non-ns timedelta units would hold the incorrect dtype (:issue:`19176`, :issue:`19223`, :issue:`12425`)
 - Bug in subtracting :class:`Series` from ``NaT`` incorrectly returning ``NaT`` (:issue:`19158`)
 - Bug in :func:`Series.truncate` which raises ``TypeError`` with a monotonic ``PeriodIndex`` (:issue:`17717`)
+- Bug :func:`Timedelta.__mod__`, :func:`Timedelta.__divmod__` where operating with timedelta-like or numeric arguments would incorrectly raise ``TypeError`` (:issue:`19365`)


can you make this in to a sub-section and give a couple of examples. also add a small example in the timedelta docs.

put it in api changes section

can you make this in to a sub-section and give a couple of examples.

Sure. For the ipython code blocks, do I copy/paste the traceback?

jreback · 2018-01-25T01:18:29Z

also see if we have any open issues related to this (maybe)

jbrockmendel · 2018-01-28T00:48:29Z

Thoughts on this? There are other dark corners of Timedelta I'd like to address after this is done.

jreback · 2018-01-29T11:10:13Z

doc/source/timedeltas.rst

+.. ipython:: python
+
+   pd.Timedelta(hours=37) % datetime.timedelta(hours=2)
+   divmod(datetime.timedelta(hours=2), pd.Timedelta(minutes=11))


give a comment or 2 hear, a dense block of code is not very friendly

just give 2 examples not need to have every case covered

don't show the array case, I find that unfriendly

jreback · 2018-01-29T11:11:10Z

doc/source/whatsnew/v0.23.0.txt

+
+.. ipython:: python
+
+    td = pd.Timedelta(hours=37)


show the td, then in another ipython block show operations on it.

jreback · 2018-01-29T11:11:21Z

doc/source/whatsnew/v0.23.0.txt

+    td % pd.Timedelta(hours=2)
+    divmod(td, np.array([2, 3], dtype='timedelta64[h]'))
+
+Previous Behavior:


there is no need to show previous behavior here.

jreback · 2018-01-29T11:11:30Z

doc/source/whatsnew/v0.23.0.txt

+
+Current Behavior
+
+.. ipython:: python


this is repetetive

jreback · 2018-01-29T11:11:56Z

doc/source/whatsnew/v0.23.0.txt

@@ -313,6 +353,7 @@ Other API Changes
 - :func:`DatetimeIndex.shift` and :func:`TimedeltaIndex.shift` will now raise ``NullFrequencyError`` (which subclasses ``ValueError``, which was raised in older versions) when the index object frequency is ``None`` (:issue:`19147`)
 - Addition and subtraction of ``NaN`` from a :class:`Series` with ``dtype='timedelta64[ns]'`` will raise a ``TypeError` instead of treating the ``NaN`` as ``NaT`` (:issue:`19274`)
 - Set operations (union, difference...) on :class:`IntervalIndex` with incompatible index types will now raise a ``TypeError`` rather than a ``ValueError`` (:issue:`19329`)
+- :func:`Timedelta.__mod__`, :func:`Timedelta.__divmod__` now accept timedelta-like and numeric arguments instead of raising ``TypeError`` (:issue:`19365`)


you are covering this above, don't repeat

As in remove this line entirely b/c the "Timedelta mod method" section above exists?

jreback · 2018-01-29T11:16:04Z

pandas/tests/scalar/test_timedelta.py

+        expected = np.array([9, 12], dtype='m8[m]').astype('m8[ns]')
+        tm.assert_numpy_array_equal(result, expected)
+
+        with pytest.raises(TypeError):


add a comment on why this is prohibiited, any other ops not allowed?

jreback · 2018-01-29T11:16:44Z

pandas/tests/scalar/test_timedelta.py

+
+        result = td + datetime(2016, 1, 1)
+        assert result == pd.Timestamp(2016, 1, 11)
+


I KNOW we have tests for this, is there a reason you are duplicating? (rather than moving those to here)?

test_ops_scalar. I have not problem adding tests, but please don't duplicate.

I KNOW we have tests for this, is there a reason you are duplicating? (rather than moving those to here)?

ATM there is NO test for Timedelta(10, unit='d') + np.timedelta64(-4, 'D') (try it; it returns a timedelta64). More generally, there are no add/sub tests in test_timedelta.

jreback · 2018-01-29T11:18:25Z

pandas/tests/scalar/test_timedelta.py

+
+    @pytest.mark.parametrize('op', [lambda x, y: x + y,
+                                    lambda x, y: y + x])
+    def test_add_timedeltalike(self, op):


these are also duplicative. pls consolidate.

tests_ops_offset. you can prob just remove that. but pls look for existing tests and modify / remove them.

Done. There's some more organizing of Timedelta arith tests I'll do in the next pass. These need to be much more thorough.

jreback · 2018-01-29T11:19:10Z

pandas/tests/scalar/test_timedelta.py

+        td = Timedelta(hours=37)
+
+        # Array-like others
+        result = td % np.array([6, 5], dtype='timedelta64[h]')


see my comment above

same comment

jreback · 2018-01-29T11:20:29Z

pandas/tests/scalar/test_timedelta.py

+        assert isinstance(result, Timedelta)
+        assert result == Timedelta(minutes=2)
+
+        result = np.array([5, 6], dtype='m8[m]') % td


see my comment above. is there a reason you are not testing TDI? (generally whenever you are testing array-like)? The array-like numerics should be with the TDI tests (if they are not in this module).

This ties in to your comments about duplication. In general when we have A.op(B) and B.rop(A) we can either put this test in test_A, test_B, or both. My preference is to order these the same way as NotImplemented behavior goes. Timedelta doesn't know anything about TDI, so test_timedelta doesn't either. (By analogy, Series doesn't know anything about DataFrame...)

jreback · 2018-02-06T01:20:53Z

can you rebase, haven't looked in a while at this.

jreback · 2018-02-09T12:10:45Z

doc/source/whatsnew/v0.23.0.txt

+Timedelta mod method
+^^^^^^^^^^^^^^^^^^^^
+
+mod (%) and divmod operations are now defined on Timedelta objects when operating with either timedelta-like or with numeric arguments. (:issue:`19365`)


use double backticks. on mod, divmod, TImedelta.

jreback · 2018-02-09T12:12:49Z

pandas/tests/scalar/test_timedelta.py

+        result = td * 1.5
+        assert result == Timedelta(minutes=4, seconds=30)
+
+        result = td * np.array([3, 4], dtype='int64')


is it easy to just return a TDI? this is very unituitive

jreback · 2018-02-09T12:13:16Z

pandas/tests/scalar/test_timedelta.py

+
+    @pytest.mark.parametrize('op', [lambda x, y: x + y,
+                                    lambda x, y: y + x])
+    def test_add_timedeltalike(self, op):


tests_ops_offset. you can prob just remove that. but pls look for existing tests and modify / remove them.

jbrockmendel · 2018-02-09T16:02:53Z

is it easy to just return a TDI? this is very unituitive

That may become viable if/when TimedeltaArray becomes a thing. For now 2D cases alone are a deal-breaker.

jreback · 2018-02-10T15:54:26Z

That may become viable if/when TimedeltaArray becomes a thing. For now 2D cases alone are a deal-breaker.

2D should be banned. return a TDI.

jbrockmendel · 2018-02-10T17:58:21Z

2D should be banned. return a TDI.

Let's call this out-of-scope. I'm not comfortable with this. Consistency would require returning Index object wherever we currently return arrays. Plus it isn't obvious that an immutable object should be returned.

jreback · 2018-02-10T18:18:01Z

then make all of these NotImplemented for now (timedelta and integer ndarray). This expands the scope too much here.

jbrockmendel · 2018-02-10T18:30:25Z

then make all of these NotImplemented for now (timedelta and integer ndarray). This expands the scope too much here.

This PR became necessary because I was trying to fix Index/Series ops wth timedelta-like. Making these ops work is preliminary to make those work.

jreback · 2018-02-10T18:35:33Z

and ndarray integers arrays are bogus here. so make those raise.

jbrockmendel · 2018-02-10T20:07:43Z

For which ops are int-dtyped ndarrays bogus?

jreback · 2018-02-10T20:12:27Z

>1 ndim

jreback · 2018-02-10T20:20:55Z

greater than 1 d

that should return a TDI

jbrockmendel · 2018-02-10T20:33:24Z

@jorisvandenbossche can you weigh in on this? I'm really uncomfortable with

a) returning TDI in timedelta64[ns] cases but ndarray in datetime/int/float cases
b) returning an immutable object (TDI) when the user didn't ask for one
c) having things that "just work" for np.timedelta64 start raising when wrapped with Timedelta (operations with ndim>1 ndarrays)
d) dropping a wedge between td.__op__(frame) vs td.__op__(frame.values)

jreback · 2018-02-10T21:07:40Z

@jbrockmendel you summary is not correct. an operation with a TDI and a 1D array should return a TDI. Not sure where your others points are coming from.

jbrockmendel · 2018-02-11T16:29:09Z

Can you open this discussion in a separate issue? This fixes specific bugs and is a blocker for fixing other specific bugs, both of which I'd rather focus on.

Not sure where your others points are coming from.

You told me to make ops with 2D ndarray raise. Of course that would cause things to break that didn't in the past.

I'll give you half a point for d) as that was incorrect. The requested change would not introduce a wedge between Timedelta.__op__(DataFrame) vs Timedelta.__op__(DataFrame.values). It would cause both to raise.

jorisvandenbossche · 2018-02-11T20:45:24Z

@jbrockmendel you summary is not correct. an operation with a TDI and a 1D array should return a TDI.

@jreback not sure if it was a typo or not, but I think the discussion is about Timedelta * ndarray, not TimedeltaIndex * ndarray (I agree that last case should return TimedeltaIndex, but that is already the case right now)

We consistently return ndarray of datetime64 / timedelta64 on operations with Timedelta scalars and ndarrays. So I agree that if we want to change this, we should do it for all cases, so let's keep that for a separate issue, and keep this PR focused on the original issue?

jorisvandenbossche · 2018-02-11T20:55:06Z

pandas/_libs/tslibs/timedeltas.pyx

@@ -492,7 +492,14 @@ def _binary_op_method_timedeltalike(op, name):
            if other.dtype.kind not in ['m', 'M']:
                # raise rathering than letting numpy return wrong answer
                return NotImplemented
-            return op(self.to_timedelta64(), other)
+            result = op(self.to_timedelta64(), other)
+            if other.ndim == 0:


Wouldn't be cleaner to do elif hasattr(other, 'dtype') and other.ndim > 0, and then let the scalar numpy ones take the route of Timedelta below ? (the other = Timedelta(other) some lines below will work for a np.timedelta64

I think that would be about a wash because we also need to handle the case where other is a 0-dim datetime64 array.

Isn't that already catched by the is_datetime64_object(other) above? (not sure what the method exactly does, but from the name I would expect that)

And from this it seems it is indeed already working correctly:

In [163]: pd.Timedelta(1) + np.datetime64(1000, 'ns') Out[163]: Timestamp('1970-01-01 00:00:00.000001001')

Yah there's some ambiguity there. The 0-dim case to watch out for is (under master, fixed in the PR):

>>> pd.Timedelta(1) + np.array('2016-01-02 03:04:05', dtype='datetime64[ns]') numpy.datetime64('2016-01-02T03:04:05.000000001')

Ah, but not sure that should be fixed?

I could see a reasonable argument that the zero-dim array op should return a zero-dim array (i.e. not a Timedelta like the PR changes it to), but given that it returns a scalar, I think the consistent thing to do is always return a Timestamp/Timedelta.

not sure we should add that much extra lines to just deal with numpy scalars vs numpy 0-dim arrays

As long as we a) aren't making spaghetti and b) are testing these new corner cases, I don't see much downside to fixing these. If there were some kind of LOC budget I'd agree with you that this would be a pretty low priority. (and if it will get this merged I'll revert this part, since this is blocking fixes to Index bugs)

. (and if it will get this merged I'll revert this part, since this is blocking fixes to Index bugs)

Can you explain why this part would be reverted again, but is needed to be first merged?

Poor use of pronouns on my part. "This part" refers to the zero-dimensional arrays, and is not the bug that originally motivated this PR, but was found in the process of writing tests for this PR. "this is blocking" referred to the divmod/mod and 1-d array ops, which I need to have here before I can fix e.g. pd.Index([0, 1, 2]) * pd.Timedelta(days=1)

I don't see any test you added that would catch this 0-dim array case. Would it be ok to just leave that out of this PR, and only fix the numpy timedelta64 scalar case?

We can discuss how many lines of code are added and whether that is worth it, but checking the result type and the potentially converting the result, does add to the code complexity. I would rather add a is_timedelta64_object(other) check to explicitly use the normal timedelta path for those.

I'm amenable to this suggestion, will update in a bit.

FYI is_timedelta64_object(obj) is equivalent to isinstance(obj, np.timedelta64). It will not catch arrays with timedelta64-dtype.

jbrockmendel · 2018-02-12T16:06:58Z

OK, just implemented ~ the suggested changes. I'd like to do another pass after this to flesh out the tests for Timedelta arithmetic ops. If this doesn't pass muster as is, I think the next step is to strip out everything except the mod/divmod and push the other arithmetic edits+tests to a separate PR.

@jorisvandenbossche Thanks for chiming in. After looking at it I agree the handling without the ndim==0 checks is prettier. You get two internet points.

jorisvandenbossche · 2018-02-12T18:25:59Z

pandas/_libs/tslibs/timedeltas.pyx

@@ -1044,6 +1047,11 @@ class Timedelta(_Timedelta):
    __rsub__ = _binary_op_method_timedeltalike(lambda x, y: y - x, '__rsub__')

    def __mul__(self, other):
+        if is_integer_object(other) or is_float_object(other):
+            # includes numpy scalars that would otherwise be caught by dtype
+            # check below


another option to do this would be if hasattr(other, 'dtype') and not (is_integer_object(other) or is_float_object(other)):
that way you don't need to repeat the Timedelta(other * self.value, unit='ns') twice

Good idea. I like having if/elif branches that are explicitly mutually explicit and so don't rely on the ordering.

jorisvandenbossche · 2018-02-13T10:43:47Z

pandas/_libs/tslibs/timedeltas.pyx

            return op(self, Timestamp(other))
            # We are implicitly requiring the canonical behavior to be
            # defined by Timestamp methods.

+        elif is_timedelta64_object(other):
+            return op(self, Timedelta(other))


you can apply the same idea here? (add the and not is_timedelta64_object(other) on the line below)

How strong is your opinion on this one? I have a slight preference for the explicitness of this ordering over the sometimes-vagueness of a catch-all.

Not that strong, but the thing is that this will then again go through this method, instead of being run once.
If you want to deal with it explicitly, you can also do something like

elif is_timedelta64_object(other): pass # other coerced to Timedelta at the bottom

jorisvandenbossche · 2018-02-13T10:45:31Z

pandas/_libs/tslibs/timedeltas.pyx

@@ -1060,7 +1065,10 @@ class Timedelta(_Timedelta):
    __rmul__ = __mul__

    def __truediv__(self, other):
-        if hasattr(other, 'dtype'):
+        if is_timedelta64_object(other):
+            return self / Timedelta(other)


same comment here (and some below as well)

jreback · 2018-02-16T18:40:49Z

doc/source/timedeltas.rst

+   divmod(datetime.timedelta(hours=2), pd.Timedelta(minutes=11))
+
+   # divmod against a numeric returns a pair (Timedelta, Timedelta)
+   pd.Timedelta(hours=25) % 86400000000000


missing the divmod here

jreback · 2018-02-16T18:41:33Z

doc/source/whatsnew/v0.23.0.txt

+    td = pd.Timedelta(hours=37)
+    td
+
+Current Behavior


you don't need the Current Behavior here (as there isn't any previous)

jreback · 2018-02-16T18:41:47Z

doc/source/whatsnew/v0.23.0.txt

+Timedelta mod method
+^^^^^^^^^^^^^^^^^^^^
+
+``mod`` (%) and ``divmod`` operations are now defined on ``Timedelta`` objects when operating with either timedelta-like or with numeric arguments. (:issue:`19365`)


you can put in a reference to the docs in the timedelta section.

I'm unclear on what this means.

jreback · 2018-02-16T18:42:03Z

doc/source/timedeltas.rst

@@ -283,6 +283,18 @@ Rounded division (floor-division) of a ``timedelta64[ns]`` Series by a scalar
   td // pd.Timedelta(days=3, hours=4)
   pd.Timedelta(days=3, hours=4) // td



add a ref tag here

You mean a "(:issue:19365)"?

no a section reference

Do you mean something like ".. _timedeltas.divmod:" after line 297?

jreback · 2018-02-16T18:43:17Z

pandas/_libs/tslibs/timedeltas.pyx

-                    return Timedelta(self.value // other)
-                else:
-                    return self.to_timedelta64() // other
+                return self.to_timedelta64() // other


does this not need wrapping in Timedelta?

@jorisvandenbossche convinced me that special-casing zero-dim np.ndarrays didn't make much sense.

that’s not the point
it’s returning a np.timedelta64 and not a Timedelta

OK, will revert. @jorisvandenbossche if you want to revisit this particular edit, mention it in #17652.

jreback · 2018-02-16T18:44:40Z

pandas/tests/scalar/test_timedelta.py

+        result = td * 1.5
+        assert result == Timedelta(minutes=4, seconds=30)
+
+        result = td * np.array([3, 4], dtype='int64')


so you haven't answered my question here. this needs to return a TDI or raise TypeError. return a m8 array is simply not useful.

jreback · 2018-02-16T18:45:59Z

pandas/tests/scalar/test_timedelta.py

+        td = Timedelta(hours=37)
+
+        # Array-like others
+        result = td % np.array([6, 5], dtype='timedelta64[h]')


same comment

jreback · 2018-02-16T18:46:12Z

pandas/tests/scalar/test_timedelta.py

+        expected = pd.TimedeltaIndex(['1H', '2H'])
+        tm.assert_index_equal(result, expected)
+
+        result = td % np.array([2, int(1e12)], dtype='i8')


here as well

jreback · 2018-02-16T18:46:25Z

pandas/tests/scalar/test_timedelta.py

+        assert result == Timedelta(minutes=2)
+
+        result = np.array([5, 6], dtype='m8[m]') % td
+        expected = np.array([2, 0], dtype='m8[m]').astype('m8[ns]')


jbrockmendel · 2018-02-16T20:24:22Z

so you haven't answered my question here. this needs to return a TDI or raise TypeError. return a m8 array is simply not useful.

I did answer by disagreeing and asking @jorisvandenbossche to weigh in. Why would an m8 array not be useful? The user clearly thinks its useful enough to pass as an input.

jbrockmendel · 2018-02-19T07:38:20Z

Closing in favor of #19755, #19752, plus followups.

implement mod, divmod, rmod, rdivmod, fix and test scalar methods

4688064

gfyoung added Testing pandas testing functions or related to the test suite Timedelta Timedelta data type labels Jan 24, 2018

gfyoung reviewed Jan 24, 2018

View reviewed changes

whatsnew, gh reference in tests

baf4d6b

jreback requested changes Jan 25, 2018

View reviewed changes

jbrockmendel added 3 commits January 24, 2018 18:36

separate tests for invalid mod and divmod

a2b1ac7

docs

8224871

fix test broken on appveyor

9558dc9

jreback requested changes Jan 29, 2018

View reviewed changes

jbrockmendel added 2 commits January 29, 2018 08:27

requested edits

f838cc9

Merge branch 'master' of https://github.com/pandas-dev/pandas into tdmod

cd421db

Merge branch 'master' of https://github.com/pandas-dev/pandas into tdmod

ed99f50

jbrockmendel changed the title ~~implement mod, divmod, rmod, rdivmod, fix and test scalar methods~~ implement Timedelta mod, divmod, rmod, rdivmod, fix and test scalar methods Feb 8, 2018

jreback requested changes Feb 9, 2018

View reviewed changes

de-dup tests, edit whatsnew

1ace838

jorisvandenbossche reviewed Feb 11, 2018

View reviewed changes

jbrockmendel added 2 commits February 12, 2018 07:43

Merge branch 'master' of https://github.com/pandas-dev/pandas into tdmod

0de3bd4

implement suggested changes to catching zero-dim numpy objs

acff328

jorisvandenbossche reviewed Feb 12, 2018

View reviewed changes

Delay int/float cases

73fd6dc

jorisvandenbossche reviewed Feb 13, 2018

View reviewed changes

jbrockmendel added 3 commits February 13, 2018 07:46

revert edit that broke floordiv

4cbb2e1

pass on is_timedelta64_object

08fa8fd

catch late-NaT

03b7e17

jbrockmendel mentioned this pull request Feb 16, 2018

Parametrize PeriodIndex tests #19659

Merged

4 tasks

jreback requested changes Feb 16, 2018

View reviewed changes

Merge branch 'master' of https://github.com/pandas-dev/pandas into tdmod

120d61f

jbrockmendel added 2 commits February 16, 2018 16:24

requested edits to docs

c1fbdc9

revert zero-dim de-specialization

b2995c9

This was referenced Feb 17, 2018

Split+Parametrize Timedelta tests #19736

Merged

Implement missing tests, fix offset floordiv, rfloordiv, fix return types #19738

Closed

dummy commit to force CI

c22dc47

jbrockmendel mentioned this pull request Feb 19, 2018

ENH: implement Timedelta.__mod__ and __divmod__ #19755

Merged

4 tasks

jbrockmendel closed this Feb 19, 2018

jorisvandenbossche added this to the No action milestone Feb 19, 2018

jbrockmendel deleted the tdmod branch April 5, 2020 17:39


		result = td + datetime(2016, 1, 1)
		assert result == pd.Timestamp(2016, 1, 11)

		@@ -283,6 +283,18 @@ Rounded division (floor-division) of a ``timedelta64[ns]`` Series by a scalar
		td // pd.Timedelta(days=3, hours=4)
		pd.Timedelta(days=3, hours=4) // td

implement Timedelta mod, divmod, rmod, rdivmod, fix and test scalar methods #19365

implement Timedelta mod, divmod, rmod, rdivmod, fix and test scalar methods #19365

Conversation

jbrockmendel commented Jan 24, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gfyoung commented Jan 24, 2018 • edited Loading

codecov bot commented Jan 24, 2018 • edited Loading

Codecov Report

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jreback commented Jan 25, 2018

jbrockmendel commented Jan 28, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jreback commented Feb 6, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jbrockmendel commented Feb 9, 2018

jreback commented Feb 10, 2018

jbrockmendel commented Feb 10, 2018

jreback commented Feb 10, 2018

jbrockmendel commented Feb 10, 2018

jreback commented Feb 10, 2018

jbrockmendel commented Feb 10, 2018

jreback commented Feb 10, 2018 • edited by jorisvandenbossche Loading

jreback commented Feb 10, 2018

jbrockmendel commented Feb 10, 2018

jreback commented Feb 10, 2018

jbrockmendel commented Feb 11, 2018

jorisvandenbossche commented Feb 11, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jbrockmendel commented Feb 12, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jorisvandenbossche Feb 13, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gfyoung commented Jan 24, 2018 •

edited

Loading

codecov bot commented Jan 24, 2018 •

edited

Loading

jreback commented Feb 10, 2018 •

edited by jorisvandenbossche

Loading

jorisvandenbossche Feb 13, 2018 •

edited

Loading