Datetime with no tzinfo will be considered UTC is spamming the logs

[carlossg]

Describe the bug

when running

az storage blob delete-batch --source SOURCE_NAME --if-unmodified-since 2023-07-18T08:20Z -account-name ACCOUNT_NAME --account-key XXX

in the docker image 2.38.0+ the logs are spammed with Datetime with no tzinfo will be considered UTC for each blob

This is due to the python upgrade in #22864 and not happening in the docker image 2.37.0

Related command

az storage blob delete-batch

Errors

Datetime with no tzinfo will be considered UTC.
Datetime with no tzinfo will be considered UTC.
Datetime with no tzinfo will be considered UTC.
Datetime with no tzinfo will be considered UTC.
Datetime with no tzinfo will be considered UTC.
Datetime with no tzinfo will be considered UTC.
Datetime with no tzinfo will be considered UTC.
Datetime with no tzinfo will be considered UTC.
Datetime with no tzinfo will be considered UTC.
Datetime with no tzinfo will be considered UTC.
...

Issue script & Debug output

debug logs

docker run -ti --rm mcr.microsoft.com/azure-cli:2.38.0 az storage blob delete-batch --source SOURCE_NAME --if-unmodified-since 2023-07-18T08:20Z -account-name ACCOUNT_NAME --account-key XXX

...
urllib3.connectionpool: https://REDACTED.blob.core.windows.net:443 "DELETE /REDACTED/x.tar.gz HTTP/1.1" 412 252
cli.azure.cli.command_modules.storage.operations.blob: The condition specified using HTTP conditional header(s) is not met.
RequestId:REDACTED
Time:2023-08-01T08:47:26.4905364Z
ErrorCode:ConditionNotMet, HttpResponseError: Operation returned an invalid status 'The condition specified using HTTP conditional header(s) is not met.'
Content: <?xml version="1.0" encoding="utf-8"?><Error><Code>ConditionNotMet</Code><Message>The condition specified using HTTP conditional header(s) is not met.
RequestId:REDACTED
Time:2023-08-01T08:47:26.4905364Z</Message></Error>
msrest.serialization: Datetime with no tzinfo will be considered UTC.
urllib3.connectionpool: https://REDACTED.blob.core.windows.net:443 "DELETE /REDACTED/y.tar.gz HTTP/1.1" 412 252
cli.azure.cli.command_modules.storage.operations.blob: The condition specified using HTTP conditional header(s) is not met.
RequestId:REDACTED
Time:2023-08-01T08:47:26.6304558Z
ErrorCode:ConditionNotMet, HttpResponseError: Operation returned an invalid status 'The condition specified using HTTP conditional header(s) is not met.'
Content: <?xml version="1.0" encoding="utf-8"?><Error><Code>ConditionNotMet</Code><Message>The condition specified using HTTP conditional header(s) is not met.
RequestId:REDACTED
Time:2023-08-01T08:47:26.6304558Z</Message></Error>
msrest.serialization: Datetime with no tzinfo will be considered UTC.

Expected behavior

Datetime with no tzinfo will be considered UTC message should not be spamming the logs

Environment Summary

❯ docker run -ti --rm mcr.microsoft.com/azure-cli:2.38.0 az --version
azure-cli                         2.38.0 *

core                              2.38.0 *
telemetry                          1.0.6 *

Dependencies:
msal                            1.18.0b1
azure-mgmt-resource             21.1.0b1

Python location '/usr/local/bin/python'
Extensions directory '/root/.azure/cliextensions'

Python (Linux) 3.10.5 (main, Jun  7 2022, 19:23:05) [GCC 11.2.1 20220219]

and

❯ docker run -ti --rm mcr.microsoft.com/azure-cli:2.51.0 az --version
azure-cli                         2.51.0

core                              2.51.0
telemetry                          1.1.0

Dependencies:
msal                            1.24.0b1
azure-mgmt-resource             23.1.0b2

Python location '/usr/local/bin/python'
Extensions directory '/root/.azure/cliextensions'

Python (Linux) 3.10.12 (main, Jun 15 2023, 03:17:49) [GCC 12.2.1 20220924]

Legal docs and information: aka.ms/AzureCliLegal


Your CLI is up-to-date.

Additional context

No response

[yonzhan]

Thank you for opening this issue, we will look into it.

[yaya2devops]

looks nice

[cwshugg]

Wanted to bump this issue - I am also seeing this when using the Azure DevOps Python API. The dates in the objects (like the creation_date field in an ADO Pull Request object) are formatted as a string in UTC. When I call this object's as_dict() function to convert it to a dictionary, the serialization seems to trigger this issue and the warning message is displayed.

Would it be possible to have these datetime values formatted as epoch seconds rather than a UTC string? I believe this would make parsing and conversion much easier while still maintaining the original timestamp. I can understand if that might break existing implementations that rely on the API; perhaps the simplest solution is to enforce the UTC timezone under the hood.