pd.Timedelta.resolution is different from datetime.timedelta.resolution

[mroeschke]

timedelta.resolution is documented as:

The smallest possible difference between non-equal timedelta objects, timedelta(microseconds=1).

while pandas.Timedelta.resolution is doc-string'd as:

return a string representing the lowest resolution that we have

In [9]: pd.Timedelta(minutes=30).resolution
Out[9]: 'T'

In [10]: timedelta(minutes=30).resolution
Out[10]: datetime.timedelta(0, 0, 1)

I think this difference should be addressed by either:

1. Documenting the difference between both but also supporting datetime.timedelta's notion of resolution in Timedelta (i.e. something that returns Timedelta(nanoseconds=1))
2. Making Timedelta.resolution consistent with timedelta.resolution and creating a new property for "the lowest resolution" of a Timedelta instance

Thoughts?

xref #21336

[gfyoung]

I would prefer option 1. Option 2 would commit us (to some extent) to tracking datetime, which is not necessarily bad, but I do prefer flexibility in general.

[drewmassey]

(Sorry this was initially posted against the wrong issue):
I'm looking at

pandas/pandas/_libs/tslibs/timedeltas.pyx

Line 797 in 9d61ab5

def resolution(self):

and I think fixing this would be breaking change ... it isn't hard to change the return values but is that really the desired behavior?

[mroeschke]

@drewmassey if we move forward with option 1. Then we would:

1. Make a note in pd.Timedelta.resolution that this is different from datetime.timedelta
2. Create a separate property for pd.Timedelta to return pd.Timedelta(nanoseconds=1)

If we move forward with option 2 then yes it would be a breaking change. I would slightly prefer option 1 as well since it doesn't disrupt the current API.

[drewmassey]

Ok I can handle this. Let me get the PR through for issue #21336 to make sure I have the pandas workflow in shape and then I'll submit this one.

[jbrockmendel]

I think we should deprecate the current behavior and eventually change it to match the stdlib. @mroeschke thoughts?

[mroeschke]

Agreed that we should match the stdlib.

[jbrockmendel]

Working on this I'm noticing that we also have Timestamp.resolution subtly different from datetime.resolution. On datetime it is a class attribute, whereas on Timestamp it is a property

[jbrockmendel]

Yikes, and pd.NaT.resolution has the datetime behavior