@ZackerySpytz The approach looks good to me, but I think it would be good to add a test here.

Is timeout something a user can specify? If timeout + now overflows, does it actually raise an error, or does it just set endtime to a negative number, causing this to time out immediately?

I also think it might be worth adding some of the details of exactly what user-facing behaviors will change with this patch to the changelog. "Avoid signed integer overflow" doesn't mean too much to me, out of context, and the BPO report is not much more detailed.

To clarify the changelog, you could say it is a timeout value that causes the overflow, and figure out what APIs are affected. I suspect some acquire method(s) of lock object(s), such as threading.Lock.acquire, but someone with an up-to-date copy of the code should confirm.

@ZackerySpytz, please take a look at the code review comments. Thanks!

@ZackerySpytz Are you interested in continuing to work on this PR?

This was fixed in #28674, as mentioned on the bpo.