I think it's worth changing these toifs andValueErrors; assertions are disabled when Python is ran with-O. (Though, it's theoretically possible that will break code for people relying onAssertionError. I'm not sure how big of an issue that is.)

the practice of calling assert is also found in other modules and I think this issue should be raised separately (not in this PR)

I think it's fine to do it in this PR, because IMO, unifying the error types fall under the category of "normalizing." I'm not super crazy about it though--any opinion@erlend-aasland?

Probably not going to be a great user experience here because of how bad thetimedelta formatter is:

>>>print(f"{timedelta(hours=-25)!r}")datetime.timedelta(days=-2,seconds=82800)

Maybe it will be clearer if we do it this way:

ifoffset<timedelta(0):offset_str=f"-{-offset)}"else:offset_str=str(offset)

That will print stuff like-1 day, 1:00:00 instead oftimedelta(days=-2, seconds=82800). Though looking at it, I realize that the way it gets printed is misleading, since that's the output you get fromprint(timedelta(hours=-23)) and users have no way of knowing what is going on under the hood there.

Probably a more elaborate timedelta formatter would be better, since we basically always want this inHH:MM:SS.fff format, since that reflects what we care about best and also is unambigous, but we don't have a particularly easy way to do that. I guess we can revisit this when/if#85426 is implemented.

@pganssle
Okay, then let's solve this issue in a separate PR linked to that issue (I can send the changes soon).
I think this one can be merged for now and I would be glad if you review another PR#127242 fordatetime module :)