Removing utcnow method deprecated at python3.12#2415
Removing utcnow method deprecated at python3.12#2415sentrivana merged 7 commits intogetsentry:masterfrom
Conversation
|
Thanks for the PR @rmad17! This works for Python 3.12 as well as older Python 3 versions, but we need to support 2.7 too, where My suggestion would be to add a new Please also run |
…y-python into 2407-support-new-utc-method
|
Thanks for the suggestion @sentrivana. I have implemented what you suggested. |
|
Should this also fix the same warnings around It seems to be called only once AFAICT: |
sentrivana
left a comment
There was a problem hiding this comment.
Looks good, just one more thing to make it work in py2!
Ah, good catch. Don't really care much if it gets its own PR. @rmad17 if you also feel like fixing what @hynek pointed out, feel free to add to this PR (not necessary though!). Otherwise I'll open a new issue for it. |
|
Thanks @sentrivana for the suggestions. I have made the changes. I have also addressed the issue @hynek pointed out. |
sentrivana
left a comment
There was a problem hiding this comment.
Thank you for squeezing in the utcfromtimestamp change as well @rmad17!
I added some typing-related stuff to make the linters happy. We should be good to go!
|
Thanks @sentrivana for merging the changes:) |
The sentry-sdk 1.32.0 released on 11th of October fixed handling of utcnow to make it future-compatible with Python 3.12. The breadcrumb timestamp returned was naive and now it is timezone aware with utc specified explicitly as timezone. This broke our tests. The change in sentry that impacted it is getsentry/sentry-python#2415 We use the opportunity also to bump sentry sdk minimum version to be 1.32.0 from very old 0.8.0 (from 2019). Sentry is a service, so they generally always want you to use the latest version, and sentry has very little requirements on its own to cause conflicts (for Python 3.8+ it only requires "certifi" without any specific limitations)
…34946) The sentry-sdk 1.32.0 released on 11th of October fixed handling of utcnow to make it future-compatible with Python 3.12. The breadcrumb timestamp returned was naive and now it is timezone aware with utc specified explicitly as timezone. This broke our tests. The change in sentry that impacted it is getsentry/sentry-python#2415 We use the opportunity also to bump sentry sdk minimum version to be 1.32.0 from very old 0.8.0 (from 2019). Sentry is a service, so they generally always want you to use the latest version, and sentry has very little requirements on its own to cause conflicts (for Python 3.8+ it only requires "certifi" without any specific limitations)
…34946) The sentry-sdk 1.32.0 released on 11th of October fixed handling of utcnow to make it future-compatible with Python 3.12. The breadcrumb timestamp returned was naive and now it is timezone aware with utc specified explicitly as timezone. This broke our tests. The change in sentry that impacted it is getsentry/sentry-python#2415 We use the opportunity also to bump sentry sdk minimum version to be 1.32.0 from very old 0.8.0 (from 2019). Sentry is a service, so they generally always want you to use the latest version, and sentry has very little requirements on its own to cause conflicts (for Python 3.8+ it only requires "certifi" without any specific limitations) (cherry picked from commit 91581c4)
…(#34946) The sentry-sdk 1.32.0 released on 11th of October fixed handling of utcnow to make it future-compatible with Python 3.12. The breadcrumb timestamp returned was naive and now it is timezone aware with utc specified explicitly as timezone. This broke our tests. The change in sentry that impacted it is getsentry/sentry-python#2415 We use the opportunity also to bump sentry sdk minimum version to be 1.32.0 from very old 0.8.0 (from 2019). Sentry is a service, so they generally always want you to use the latest version, and sentry has very little requirements on its own to cause conflicts (for Python 3.8+ it only requires "certifi" without any specific limitations) (cherry picked from commit 91581c4991e0f81ac60c64bbaaf31eb51d65922a) GitOrigin-RevId: a2b0a6aab814a773a7ba0a14f648a77d1dfdbb82
…(#34946) The sentry-sdk 1.32.0 released on 11th of October fixed handling of utcnow to make it future-compatible with Python 3.12. The breadcrumb timestamp returned was naive and now it is timezone aware with utc specified explicitly as timezone. This broke our tests. The change in sentry that impacted it is getsentry/sentry-python#2415 We use the opportunity also to bump sentry sdk minimum version to be 1.32.0 from very old 0.8.0 (from 2019). Sentry is a service, so they generally always want you to use the latest version, and sentry has very little requirements on its own to cause conflicts (for Python 3.8+ it only requires "certifi" without any specific limitations) GitOrigin-RevId: 91581c4991e0f81ac60c64bbaaf31eb51d65922a
…(#34946) The sentry-sdk 1.32.0 released on 11th of October fixed handling of utcnow to make it future-compatible with Python 3.12. The breadcrumb timestamp returned was naive and now it is timezone aware with utc specified explicitly as timezone. This broke our tests. The change in sentry that impacted it is getsentry/sentry-python#2415 We use the opportunity also to bump sentry sdk minimum version to be 1.32.0 from very old 0.8.0 (from 2019). Sentry is a service, so they generally always want you to use the latest version, and sentry has very little requirements on its own to cause conflicts (for Python 3.8+ it only requires "certifi" without any specific limitations) GitOrigin-RevId: 91581c4991e0f81ac60c64bbaaf31eb51d65922a
…(#34946) The sentry-sdk 1.32.0 released on 11th of October fixed handling of utcnow to make it future-compatible with Python 3.12. The breadcrumb timestamp returned was naive and now it is timezone aware with utc specified explicitly as timezone. This broke our tests. The change in sentry that impacted it is getsentry/sentry-python#2415 We use the opportunity also to bump sentry sdk minimum version to be 1.32.0 from very old 0.8.0 (from 2019). Sentry is a service, so they generally always want you to use the latest version, and sentry has very little requirements on its own to cause conflicts (for Python 3.8+ it only requires "certifi" without any specific limitations) GitOrigin-RevId: 91581c4991e0f81ac60c64bbaaf31eb51d65922a
…(#34946) The sentry-sdk 1.32.0 released on 11th of October fixed handling of utcnow to make it future-compatible with Python 3.12. The breadcrumb timestamp returned was naive and now it is timezone aware with utc specified explicitly as timezone. This broke our tests. The change in sentry that impacted it is getsentry/sentry-python#2415 We use the opportunity also to bump sentry sdk minimum version to be 1.32.0 from very old 0.8.0 (from 2019). Sentry is a service, so they generally always want you to use the latest version, and sentry has very little requirements on its own to cause conflicts (for Python 3.8+ it only requires "certifi" without any specific limitations) GitOrigin-RevId: 91581c4991e0f81ac60c64bbaaf31eb51d65922a
…(#34946) The sentry-sdk 1.32.0 released on 11th of October fixed handling of utcnow to make it future-compatible with Python 3.12. The breadcrumb timestamp returned was naive and now it is timezone aware with utc specified explicitly as timezone. This broke our tests. The change in sentry that impacted it is getsentry/sentry-python#2415 We use the opportunity also to bump sentry sdk minimum version to be 1.32.0 from very old 0.8.0 (from 2019). Sentry is a service, so they generally always want you to use the latest version, and sentry has very little requirements on its own to cause conflicts (for Python 3.8+ it only requires "certifi" without any specific limitations) GitOrigin-RevId: 91581c4991e0f81ac60c64bbaaf31eb51d65922a
…(#34946) The sentry-sdk 1.32.0 released on 11th of October fixed handling of utcnow to make it future-compatible with Python 3.12. The breadcrumb timestamp returned was naive and now it is timezone aware with utc specified explicitly as timezone. This broke our tests. The change in sentry that impacted it is getsentry/sentry-python#2415 We use the opportunity also to bump sentry sdk minimum version to be 1.32.0 from very old 0.8.0 (from 2019). Sentry is a service, so they generally always want you to use the latest version, and sentry has very little requirements on its own to cause conflicts (for Python 3.8+ it only requires "certifi" without any specific limitations) GitOrigin-RevId: 91581c4991e0f81ac60c64bbaaf31eb51d65922a
…(#34946) The sentry-sdk 1.32.0 released on 11th of October fixed handling of utcnow to make it future-compatible with Python 3.12. The breadcrumb timestamp returned was naive and now it is timezone aware with utc specified explicitly as timezone. This broke our tests. The change in sentry that impacted it is getsentry/sentry-python#2415 We use the opportunity also to bump sentry sdk minimum version to be 1.32.0 from very old 0.8.0 (from 2019). Sentry is a service, so they generally always want you to use the latest version, and sentry has very little requirements on its own to cause conflicts (for Python 3.8+ it only requires "certifi" without any specific limitations) GitOrigin-RevId: 91581c4991e0f81ac60c64bbaaf31eb51d65922a
Replacing
datetime.utcnow()due to deprecation as discussed in #2407