DeprecationWarning: datetime.datetime.utcfromtimestamp #11608
Assignees
Labels
Profiling
Continous Profling
Comments
wantsui
added
Profiling
2 tasks
|
@joaonsantos - Thank you for reporting this! I am taking an attempt to switch it over and am getting it reviewed: #11850 . In terms of workarounds, I can only think of filterwarnings on the Python side to filter out to datetime messages: Another option that I can think of is possibly a logs exclusion filter, but this still causes the logs to hit Live Tail first. More details can be found here: https://docs.datadoghq.com/logs/log_configuration/indexes/#exclusion-filters . |
wantsui
added a commit
that referenced
this issue
Jan 9, 2025
…1850) See #11608 and #11497. Starting with [Python 3.12](https://docs.python.org/3/whatsnew/3.12.html), there were changes to datetime: > [datetime](https://docs.python.org/3/library/datetime.html#module-datetime): [datetime.datetime](https://docs.python.org/3/library/datetime.html#datetime.datetime)’s [utcnow()](https://docs.python.org/3/library/datetime.html#datetime.datetime.utcnow) and [utcfromtimestamp()](https://docs.python.org/3/library/datetime.html#datetime.datetime.utcfromtimestamp) are deprecated and will be removed in a future version. Instead, use timezone-aware objects to represent datetimes in UTC: respectively, call [now()](https://docs.python.org/3/library/datetime.html#datetime.datetime.now) and [fromtimestamp()](https://docs.python.org/3/library/datetime.html#datetime.datetime.fromtimestamp) with the tz parameter set to [datetime.UTC](https://docs.python.org/3/library/datetime.html#datetime.UTC). (Contributed by Paul Ganssle in [gh-103857](python/cpython#103857).) The result is that the usage of **utcnow** and **utcfromtimestamp** now throw deprecation warnings when used, ie: > DeprecationWarning: datetime.datetime.utcfromtimestamp() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.datetime.fromtimestamp(timestamp, datetime.UTC). There's a difference of `+00:00` between the old version and the new format. **For utcnow -> now** - `datetime.datetime.utcnow().isoformat()` | `'2025-01-02T19:51:32.579733'` - `datetime.datetime.now(datetime.timezone.utc).isoformat()` | `'2025-01-02T19:51:02.275232+00:00'` **For utcfromtimestamp -> fromtimestamp** Assume that `end_time_ns=1735848645000000000`: - `(datetime.datetime.fromtimestamp(end_time_ns / 1e9, tz=datetime.timezone.utc).replace(microsecond=0).isoformat() + "Z")` - returns `'2025-01-02T20:10:45+00:00Z'` - `(datetime.datetime.utcfromtimestamp(end_time_ns / 1e9).replace(microsecond=0).isoformat() + "Z")` - returns `'2025-01-02T20:10:45Z'` As a result, I attempted remove the trailing ones to be consistent with the old format, but can bring it back. ## Checklist - [x] PR author has checked that all the criteria below are met - The PR description includes an overview of the change - The PR description articulates the motivation for the change - The change includes tests OR the PR description describes a testing strategy - The PR description notes risks associated with the change, if any - Newly-added code is easy to change - The change follows the [library release note guidelines](https://ddtrace.readthedocs.io/en/stable/releasenotes.html) - The change includes or references documentation updates if necessary - Backport labels are set (if [applicable](https://ddtrace.readthedocs.io/en/latest/contributing.html#backporting)) ## Reviewer Checklist - [x] Reviewer has checked that all the criteria below are met - Title is accurate - All changes are related to the pull request's stated goal - Avoids breaking [API](https://ddtrace.readthedocs.io/en/stable/versioning.html#interfaces) changes - Testing strategy adequately addresses listed risks - Newly-added code is easy to change - Release note makes sense to a user of the library - If necessary, author has acknowledged and discussed the performance implications of this PR as reported in the benchmarks PR comment - Backport labels are set in a manner that is consistent with the [release branch maintenance policy](https://ddtrace.readthedocs.io/en/latest/contributing.html#backporting)
|
As an update: I was able to get a fix for this merged: #11850 . I'm expecting this to be available next release but I'll update this thread if anything changes. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Summary of problem
When using python 3.12 and ddtrace
2.14.4we get a deprecation warning:This started burning through our log quota and the alternative is to add a warnings filter which is not ideal.
The text was updated successfully, but these errors were encountered: