Here is a first review.

I suggest to declare that PyTime_t is a number of nanoseconds and not add PyTime_AsNanoseconds().

There are some Sphinx warnings, like:c:identifier reference target not found: result intime.rst.

The fallible APIs and generalization ofPyTime_t makes these APIs harder to use without, it seems to me, sufficient benefit:

• API users are likely to start relying on details, like the fact thatPyTime_t is 64-bit time in nanoseconds. If we ever in the future wanted an API with a different precision or data type, we'd be better off introducing a new API than breaking users.
• The underlying functions shouldn't fail on modern operating systems. Is there any OS we support that doesn't haveCLOCK_MONOTONIC?

I commented below, but I don't think we can set+clear exceptions in the internal versions. They're used in contexts that don't have active PyThreadStates.

LGTM.

For a few seconds (or many nanoseconds ;-)), I tried to imagine how the API and the implementation would look withoutPyTime_t type: usingint64_t type. It's tempting to make the API as small as possible. IMO the API isbetter with a decided type, even if it's well documented that it's exactlyint64_t. In terms of typing, it's better, it makes the code easier to follow, to review, etc.