So before, this returned a datetime.timedelta, as that can hold such big values.

cc @jbrockmendel do you know if this was removed intentionally?

do you know if this was removed intentionally?

I don't think so. Best guess is it was either when changing the behavior to return NotImplemented in more cases, or just a cleanup gone wrong

Mmm what behavior do we want going forward? Returning a datetime.timedelta only sometimes seems not great... I don't think we would introduce that behavior if it wasn't what we previously did.

Returning a timedelta instead of raising also has the problem that in introduces an inconsistency between Timestamp vs DTA/DTI/Series[dt64], so i lean towards not restoring the older behavior.

But we can definitely do a better exception message.

That sounds good to me. As a workaround, users can explicitly convert to a datetime.timedelta prior to performing the operation.

What behavior do we want long-term? With #32499, I'm (re-)introducing a value-dependent behavior where the return time of Timestamp - datetime.datetime depends on the values,

# out-of-bounds -> datetime.timedelta
In [5]: (pd.Timestamp.max - datetime.datetime(1960, 1, 1))
Out[5]: datetime.timedelta(days=110404, seconds=85636, microseconds=854775)

# in-bounds -> datetime.Timedelta
In [6]: (pd.Timestamp.max - datetime.datetime(2000, 1, 1))
Out[6]: Timedelta('95794 days 23:47:16.854775')

Do we want to deprecate Out[5], so that Timestamp - datetime.datetime is always a Timedelta?

I think for 1.0.2 we're fine to return a datetime.timedelta there without a warning, but we should maybe add a deprecation for 1.1.

Perhaps since we're subclassing the builtins, it's OK to return a datetime.timedelta depending on the value?

If we're issuing a warning i think its fine.