Boto3 UTC DeprecationWarnings

[BookWorm0]

Describe the bug

Running the attached script under Python 3.12 with Python flag -Wa produces DepricationWarnings.
bug.txt

Expected Behavior

No warnings should be issued.

Current Behavior

For "import boto3", the warning is: dateutil\tz\tz.py:37: 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).
EPOCH = datetime.datetime.utcfromtimestamp(0)

For s3client.list_objects, the warning is: botocore\auth.py:419: DeprecationWarning: datetime.datetime.utcnow() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.datetime.now(datetime.UTC).
datetime_now = datetime.datetime.utcnow()

Reproduction Steps

Rename the script from bug.txt to bug.py.

Run the script as follows from CMD.EXE:
py -Wa bug.py BUCKETNAME

where BUCKETNAME identifies an S3 bucket to which you are authorized to access.

Possible Solution

Boto source code should be modified as suggested in the warnings.

Additional Information/Context

No response

SDK version used

boto3-1.28.61 botocore-1.31.61

Environment details (OS name and version, etc.)

Windows 10 Pro Version 10.0.19045 Build 19045; Python 3.12.0

[tim-finnigan]

Hi @BookWorm0 thanks for reaching out. The team is aware of this issue and working on addressing the warnings. These deprecations won't cause impact currently beyond the warnings. The required changes are not fully backwards compatible for existing usage. We'll be prioritizing a more robust fix in an upcoming release.

[kfrydel]

@tim-finnigan Thank you very much!

[StevenMapes]

Any update on this as the warnings break my CI/CD flow unless I turn off error::DeprecationWarning which I really don't want to

[alex-morgun]

Add pytest decorator to affected tests, if you use pytest
@pytest.mark.filterwarnings("ignore:datetime.datetime.utcnow")

[nathanagez]

Hello @tim-finnigan, any updates on this?

[antoniogamizbadger]

Any updates on this?

[aronyanez10]

Do you happen to have any updates on this?

[Zedstron]

Any update regarding this, I am using Django and recently updated my python version from 3.9 to 3.12, and I simply can't ignore the warnings in multiple Django apps, as there are so many places using botocore.

[StevenMapes]

Any update regarding this, I am using Django and recently updated my python version from 3.9 to 3.12, and I simply can't ignore the warnings in multiple Django apps, as there are so many places using botocore.

It needs this PR on botocore to be merged in and released

[Zedstron]

So why they are not merging it? how can I use that PR in my project?

Any update regarding this, I am using Django and recently updated my python version from 3.9 to 3.12, and I simply can't ignore the warnings in multiple Django apps, as there are so many places using botocore.

It needs this PR on botocore to be merged in and released

[MedAzizTousli]

Any updates on this?

[tim-finnigan]

Thanks all for your patience. The team is continuing to track this in the backlog — please feel free to 👍 the issue to +1 it. As mentioned in a related PR:

Unfortunately, this isn't as straight forward as replacing a function call. We already attempted this in 96ca907 when 3.12 support was released and needed to roll it back due to breaking date serialization changes.

We're currently looking at removing the warnings long term in a backwards compatible manner, but don't have a timeline to provide. The utcnow deprecation is currently slated sometime after Python 3.16, so it's at least few years out. We'll work on getting it addressed more timely.

[kurtmckee]

@tim-finnigan,

breaking date serialization changes

Does boto/botocore#3239 address this problem in a way that avoids the "breaking date serialization" problem?

If not, please leave feedback on that PR that points out the specific way that the date serialization breaks (and -- ideally -- a test case that I can use to ensure that PR addresses the problem).

Thanks!

[joaonsantos]

@tim-finnigan Any updates on this? This is burning through our log quota. Any alternatives other than filter warnings?