Context

While working on PYTHON-5965 I found another performance optimzation.

Encoding a tz-aware datetime in the BSON C encoder subtracts the utcoffset() result with PyNumber_Subtract (value - utcoffset), which allocates a second tz-aware datetime just to obtain UTC milliseconds (millis). For the timezone case the offset is a timedelta, so the subtraction and the allocation it causes are unnecessary.

We can instead read the offset timedelta's fields directly with the native C-API macros, compute the offset in millis, and subtract it from the naive millis returned by the existing millis_from_datetime(value). No second datetime is allocated and no getattr on the offset is needed.

Initial benchmarks showed a ~20% improvement in the the raw performance of tz-aware datetime encode.

Definition of done

• tz-aware datetime encode throughput improves as measured with a targeted benchmark and against the relevant benchmark data files.
• test_bson.py, test_bson_corpus.py, test_raw_bson_shared.py pass

Pitfalls

What should the implementer watch out for? What are the risks?