The static method amqpstorm.message.Message.create() calls datetime.utcnow(), which has been deprecated, unless the "timestamp" property is included in the call.
I've seen two common ways to fix this:
- Use
datetime.datetime.now(datetime.UTC), which gives a timezone-aware timestamp. The reasons I've seen for this not being used related to API stability (an "unaware" datetime and an aware one are slightly different in behavior).
- If a "timezone unaware" object is really needed, calling
.replace(tzinfo=None) will turn it into one.
However to me, solution 2 seems a bit pointless because pamqp just sets tzinfo=UTC during serialization if the is datetime instance is "unaware": https://github.com/gmr/pamqp/blob/main/pamqp/encode.py#L246-L250
The cpython issue discussing the deprecation and the the reasoning behind it: python/cpython#103857
The static method
amqpstorm.message.Message.create()callsdatetime.utcnow(), which has been deprecated, unless the "timestamp" property is included in the call.I've seen two common ways to fix this:
datetime.datetime.now(datetime.UTC), which gives a timezone-aware timestamp. The reasons I've seen for this not being used related to API stability (an "unaware"datetimeand anawareone are slightly different in behavior)..replace(tzinfo=None)will turn it into one.However to me, solution 2 seems a bit pointless because
pamqpjust setstzinfo=UTCduring serialization if the isdatetimeinstance is "unaware": https://github.com/gmr/pamqp/blob/main/pamqp/encode.py#L246-L250The cpython issue discussing the deprecation and the the reasoning behind it: python/cpython#103857