BUG(?): Var of Timedelta with empty / NA

[TomAugspurger]

edit: it seems like the bug is that var returns numeric values for the operation, instead of timedeltas like .std (#18880 (comment))

---

Working on the empty / all-NA stuff. This is related, but separate.

Currently for an all-NA series of timedelta's, we return NaT for .var() on an empty series (see Out[44]). I think this should be NaN since the reduction is returning numeric values, not timedeltas.

In [40]: s = pd.Series(pd.timedelta_range(0, periods=12, freq='S'))

In [41]: s[0] = np.nan

In [42]: s.var()
Out[42]: 1.1e+19

In [43]: s.var(skipna=False)
Out[43]: nan

In [44]: s[:0].var()
Out[44]: NaT

I've just noticed some other buggy behavior with aggregations on timedeltas, so maybe this can become a meta-issue about timedeltas and numeric aggregations:

In [57]: s.sum(skipna=False)
Out[57]: Timedelta('-106752 days +00:13:49.145223')

I'm guessing we improperly add the timedelta min here.

[TomAugspurger]

Ahh interesting, .std returns the units in timedelta's so maybe that's the bug that .var isn't handling dtypes correctly:

In [11]: s.std()
Out[11]: Timedelta('0 days 00:00:03.316624')

In [12]: s[:0].std()
Out[12]: NaT

[jreback]

what would this be numeric? any reduction should stay the same dtype (except int-> float).

[jreback]

yeah it prob doesn't does handle the ufunc propertly (sqrt), e.g.

This works, but prob not what its doing.

In [7]: pd.Timedelta(np.sqrt(s.std().value))
Out[7]: Timedelta('0 days 00:00:00.000057')

[TomAugspurger]

Yeah, I was just saying numeric because the non-NA versions were numeric, but that's the real bug. I'll edit the original bug report.

[JesperDramsch]

Should this be closed? @TomAugspurger

[TomAugspurger]

I don't think so, do you? Series[timedelta].var() is still numeric for me, rather than a Timedelta.

[jbrockmendel]

Shouldnt Series[timedelta].var() raise? std() makes sense.