BUG: groupby.sum with timedelta64 and NaT

[jbrockmendel]

• closes BUG:dataframe.groupby('some_column').timedelta.sum() results wrong when timedelta contains NaT (pandas=1.3.0) #42659
• tests added / passed
• Ensure all linting tests pass, see here for how to run them
• whatsnew entry

[jreback]

if this is for backport can you add a whatsnew for 1.3.5

[jreback]

@meeseeksdev backport 1.3.x

[jreback]

cc @jbrockmendel as suspected, needs a manual backport.

[jbrockmendel]

having a hard time with the cherrypick. flake8 complains about the cython syntax at the git cherry-pick --continue step. this happens frequently and ive gotten used to ignoring it with --no-verify. but with git cherrypick --continue there is no --no-verify option.

[jbrockmendel]

cc @simonjayhawkins any idea how to handle the cherrypick problem?

[simonjayhawkins]

cc @simonjayhawkins any idea how to handle the cherrypick problem?

didn't have any.

PS. Thanks for the PR.

[simonjayhawkins]

At first glance this appears to cause a slowdown of up to 2x for several benchmarks, but including the cython 0.29.21 results it appears the reported regressions on the 1.3.x tracker could be false positives?

https://simonjayhawkins.github.io/fantastic-dollop/#series_methods.Mode.time_mode?branch=1.3.x&p-N=100000&p-dtype='int'&commits=d3a92ff9

[jbrockmendel]

At first glance this appears to cause a slowdown of up to 2x for several benchmarks

Looking at the diff, the only non-invasive optimization I see is doing <float64_t>NPY_NAT just once at the module level. Hard to imagine that making a big dent.

but including the cython 0.29.21 results it appears the reported regressions on the 1.3.x tracker could be false positives?

yah those look pretty darn noisy. is "wait a couple days for more data" a viable option?

[jreback]

this is not worth holding up 1.3.x