WIP, MAINT: upstream timedelta64 changes
State: closed

**Background:** In NumPy, I've been working to expand the operations supported for `np.timedelta64` (`m8`) operands, adding support for modulus, floordiv and divmod operations. Historically, we've allowed casting from integer and bool types to `m8`, which may seem innocent enough, but is arguably sloppy from a units perspective.

Furthermore, with the introduction of new `m8` operation support, signed and unsigned integers are now able to interconvert in [undesirable ways](https://github.com/numpy/numpy/issues/12927) by sneaking through casts to `m8`. So, core devs have suggested [prohibiting casts from int / bool types to `m8`](https://github.com/numpy/numpy/pull/13061). A prime concern here for me is the effect on downstream libraries that are known to heavily use datetime operations, like `pandas`.

**Feedback**: It would be great to get some feedback here from the `pandas` perspective. To get the discussion started, I've opened this PR with some perhaps crude changes that allow the `pandas` master branch test suite to pass for me locally (via `./test_fash.sh` anyway) with the NumPy feature branch linked above. 

How disruptive is this for you? Will we need to issue warnings / deprecate? Should we just not do this at all?

Labels:
name: Timedelta
description: Timedelta data type
name: Compat
description: pandas objects compatability with Numpy or Python functions

Comments:
# [Codecov](https://codecov.io/gh/pandas-dev/pandas/pull/25826?src=pr&el=h1) Report
> Merging [#25826](https://codecov.io/gh/pandas-dev/pandas/pull/25826?src=pr&el=desc) into [master](https://codecov.io/gh/pandas-dev/pandas/commit/cd057c7a3675354ffdf6fbd1939fa84b6c06ded2?src=pr&el=desc) will **decrease** coverage by `<.01%`.
> The diff coverage is `n/a`.

[![Impacted file tree graph](https://codecov.io/gh/pandas-dev/pandas/pull/25826/graphs/tree.svg?width=650&token=eZ4WkYLtcO&height=150&src=pr)](https://codecov.io/gh/pandas-dev/pandas/pull/25826?src=pr&el=tree)

```diff
@@            Coverage Diff             @@
##           master   #25826      +/-   ##
==========================================
- Coverage    91.3%    91.3%   -0.01%     
==========================================
  Files         173      173              
  Lines       53004    53004              
==========================================
- Hits        48397    48396       -1     
- Misses       4607     4608       +1
```

| Flag | Coverage Δ | |
|---|---|---|
| #multiple | `89.87% <ø> (ø)` | :arrow_up: |
| #single | `41.77% <ø> (ø)` | :arrow_up: |

| [Impacted Files](https://codecov.io/gh/pandas-dev/pandas/pull/25826?src=pr&el=tree) | Coverage Δ | |
|---|---|---|
| [pandas/util/testing.py](https://codecov.io/gh/pandas-dev/pandas/pull/25826/diff?src=pr&el=tree#diff-cGFuZGFzL3V0aWwvdGVzdGluZy5weQ==) | `89.3% <0%> (-0.11%)` | :arrow_down: |

------

[Continue to review full report at Codecov](https://codecov.io/gh/pandas-dev/pandas/pull/25826?src=pr&el=continue).
> **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta)
> `Δ = absolute <relative> (impact)`, `ø = not affected`, `? = missing data`
> Powered by [Codecov](https://codecov.io/gh/pandas-dev/pandas/pull/25826?src=pr&el=footer). Last update [cd057c7...b0abd46](https://codecov.io/gh/pandas-dev/pandas/pull/25826?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).

This is _great_.  We’ve had to implement patches to get the behavior you’re describing.  Having that in numpy would let us rip out a bunch of code.
Just to summarize the only non-trivial change here:

```python
arr = np.array([0, 1, 2], dtype='m8[s]')
np.sum(arr) # works
arr[0] + arr[1] + arr[2] # works
# The following doesn't work--CPython must
# try to work with ints and cast back?
sum(arr)
# numpy.core._exceptions.UFuncTypeError: Cannot cast ufunc 'add' input 0 from dtype('int64') to dtype('<m8[s]') with casting rule 'same_kind'
```

I'll mirror that code block in the cognate NumPy casting PR to see if there are any concerns on their end. Not sure much can be done about the built-in `sum`.
Ah, @eric-wieser [noted](https://github.com/numpy/numpy/pull/13061#issuecomment-475708642) this is because

> Builtin sum adds 0 as a default. sum(arr, datetime64(0)) works fine
thanks @tylerjereddy