WIP, MAINT: upstream timedelta64 changes

[tylerjereddy]

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 by sneaking through casts to m8. So, core devs have suggested prohibiting casts from int / bool types to m8. 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?

[codecov]

Codecov Report

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

@@            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% <ø> (ø)	⬆️
#single	41.77% <ø> (ø)	⬆️

Impacted Files	Coverage Δ
pandas/util/testing.py	89.3% <0%> (-0.11%)	⬇️

---

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 cd057c7...b0abd46. Read the comment docs.

[jbrockmendel]

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.

[tylerjereddy]

Just to summarize the only non-trivial change here:

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.

[tylerjereddy]

Ah, @eric-wieser noted this is because

Builtin sum adds 0 as a default. sum(arr, datetime64(0)) works fine

[jreback]

thanks @tylerjereddy