BUG: Series[timdelta64].var() should _not_ work
- [x] closes #18880
- [x] tests added / passed
- [x] passes `black pandas`
- [x] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [ ] whatsnew entry

Haven't deeply read the issue this closes but is this the agreed upon route? This would still allow `std` to work just not `var` right? That seems kind of strange to me though I'm not super familiar in this area > This would still allow `std` to work just not `var` right?

Correct, `std` is still allowed while `var` is not.

> That seems kind of strange to me though I'm not super familiar in this area

Some discussion of why this is the correct behavior in #18880.  Recapping that:

Suppose `X` is some quantity with a unit `u` (e.g. meters, or kilograms, or seconds, or in this case nanoseconds).  The `mean(X)` has that same unit `u`.  `Var(X)` has unit `u^2`.

In the case where `u` is `nanoseconds`, we do not have any way of representing `u^2`, so cannot return a correct answer for `Var(X)`.

`std(X)` is defined as `sqrt(Var(X))`, which has unit `sqrt(u^2)`, which is just `u`, which we can handle correctly. So IIUC it's mostly a technical limitation in expression `u^2` since precision is in nanosecond? > So IIUC it's mostly a technical limitation in expression u^2 since precision is in nanosecond?

"technical limitation" yes, "precision is in nanosecond" not clear.  It's not about the "nano" precision being squared, its about the "timedelta" being squared. Don't want to go too far off the rails but does the arithmetic here work generally? I guess I could see an end user constructing something as follows:

```python
>>> ser = pd.Series([pd.Timedelta("1S"), pd.Timedelta("3S")])

# std should be 1S but isn't?
>>> ser.std()
Timedelta('0 days 00:00:01.414213')
# var should be 1S maybe as well?
>>> std.var()
2e+18
```

I suppose for scope of this PR maybe disallowing the second is fine, but shouldn't the former be disallowed then as well? May be better than buggy if I've got my math right until someone wants to come along and fully implement
 the `std` result not being 1 second is a result of the `ddof` (denominator(?) degree of freedom) correction that is dividing by `len(ser) - 1` instead of `len(ser)`.  So if you do `ser.std(ddof=0)` you'll get the result you expect. Ah good catch...
 > Can you also add a whatsnew that this explicitly raises a TypeError?

Sure conflict, plus a comment above gentle ping.  more reductions to implement after this I don't think my comments above were addressed. the code change is duplicative, if you can find a way to combine with the existing routines. > I don't think my comments above were addressed. the code change is duplicative, if you can find a way to combine with the existing routines.

I replied to your comment suggesting that nanstd should go through nanvar: that is not a viable option. thanks