API: Timedelta constructor from keywords give microseconds

[jbrockmendel]

• closes #xxxx (Replace xxxx with the GitHub issue number)
• Tests added and passed if fixing a bug or adding a new feature
• All code checks passed.
• Added type annotations to new arguments/methods/functions.
• Added an entry in the latest doc/source/whatsnew/vX.X.X.rst file if fixing a bug or adding a new feature.
• If I used AI to develop this pull request, I prompted it to follow AGENTS.md.

Discussed in today's dev meeting. There is one test that is currently failing but will pass once #63018 is merged

[jorisvandenbossche]

Looks good!

The actual Timedelta constructor with kwargs, is that tested much?
I was checking pandas/tests/scalar/timedelta/test_constructors.py, and there is test_td_constructor_on_nanoseconds, but maybe you could at least add an explicit test for Timedelta(nanoseconds=1000) still having nanoseconds, as well as something like Timedelta(microseconds=1.5) to cover the check whether to convert to microseconds or not?

[jorisvandenbossche]

We should probably create some todo to try to parse to microseconds if this is out of bounds for nanoseconds?

[jorisvandenbossche]

I was wondering why this would be needed, but I suppose it is because the expected will have ns. But now the array inference PR is merged, this change can be (or needs to be) reverted?

[jbrockmendel]

@mroeschke the CI failures look unrelated, but im not seeing them on other PRs so im at a loss. any thoughts? (this is the last RC blocker)

[jorisvandenbossche]

We already have

            elif (
                isinstance(tz, tzlocal)
                and is_platform_windows()
                and _offset in (QuarterEnd, BQuarterBegin, BQuarterEnd)
            ):
                request.applymarker(
                    pytest.mark.xfail(reason="After GH#49737 t.tzinfo is None on CI")
                )

in that test, so it seems we already encountered similar issues before. Given that, I think it would be fine to expand that xfail condition on the short term

[mroeschke]

Yeah looks like we're hitting dateutil/dateutil#197 from dateutil. This exception is hit in _localize_tso which is marked noexcept

[jbrockmendel]

Updated to expand xfail

[jbrockmendel]

Green

[mroeschke]

Thanks @jbrockmendel