Thanks for this PR!

I think that it is a net benefit over what we have today, but I do think it's probably pretty inefficient, and considering we're already in C-land, maybe we can just directly call the C functions underlying timedelta addition instead of constructing a timedelta for this?

I think what you need to do to accomplish that is basically convert the timestamp parameter to an integer number of seconds and microseconds, then do something like:

int year = 1970;
int month = 1;
int day = 1;
int hour = 0;
int minute = 0;
int second = seconds;
int microsecond = microseconds;
normalize_datetime(&year, &month, &day, &hour, &minute, &second, &microsecond);

Then construct a datetime object with the results.

Calling normalize_datetime() doesn't work since seconds has time_t time, whereas the function only accepts int.

Calling normalize_datetime() doesn't work since seconds has time_t time, whereas the function only accepts int.

I am suggesting that we make the proper conversions, which will be almost certainly be dramatically more efficient than converting everything to timedelta and constructing at least 2 datetime objects.

In the end it's not a big deal to be inefficient here, because it's a pretty rare situation that wasn't even possible before, but we might as well do it now rather than wait for someone to notice and show up with a new issue "negative timestamps on windows are dramatically slower than positive ones!"

Actually it occurs to me that if we just split into seconds and microseconds we will overflow in the late 19th century. I think it is best to convert to (hours, seconds, microseconds), then normalize the datetime. That will give 244k years, which is well outside the range supported by datetime.

I merged a different fix instead: #143463. Thanks for your contribution anyway ;-)

@vstinner With respect to #143463 if anyone ever continues this work, it could potentially be a fallback to extend the range of datetime module catching on errors thrown from any given platforms native support. Just throwing that out there since the solutions don't overlap much implementation-wise.