Description

wjandrea

opened on Jul 4, 2023

Issue body actions

Bug report

The UTC deprecation warnings (added in #103858) use the name datetime to refer to both the object and the module, which is confusing. Like, if I copy-paste the code from the warnings, it doesn't work:

>>> import datetime
>>> datetime.datetime.utcnow()
<stdin>:1: DeprecationWarning: datetime.utcnow() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.now(datetime.UTC).
datetime.datetime(2023, 7, 3, 23, 35, 25, 850070)
>>> datetime.now(datetime.UTC)  # <-- Copy-pasted but doesn't work
  ...
AttributeError: module 'datetime' has no attribute 'now'
>>> datetime.datetime.now(datetime.UTC)  # Fixed
datetime.datetime(2023, 7, 3, 23, 35, 32, 898186, tzinfo=datetime.timezone.utc)
>>> 
>>> timestamp = 0
>>> datetime.datetime.utcfromtimestamp(timestamp)
<stdin>:1: DeprecationWarning: datetime.utcfromtimestamp() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.fromtimestamp(timestamp, datetime.UTC).
datetime.datetime(1970, 1, 1, 0, 0)
>>> datetime.fromtimestamp(timestamp, datetime.UTC)  # <-- Copy-pasted but doesn't work
  ...
AttributeError: module 'datetime' has no attribute 'fromtimestamp'
>>> datetime.datetime.fromtimestamp(timestamp, datetime.UTC)  # Fixed
datetime.datetime(1970, 1, 1, 0, 0, tzinfo=datetime.timezone.utc)

To fix it, I'd just put datetime.datetime where necessary. LMK if you want me to submit a PR.

By the way

#104542 brought up the same thing about the deprecated names, but I think it's fine personally:

It's really datetime.datetime.utcnow() and datetime.datetime.utcfromtimestamp(), and not datetime.utcnow() and datetime.utcfromtimestamp().

#105544 might also be relevant, I'm not sure.

Your environment

• CPython versions tested on: 3.12.0b3
• Operating system and architecture: Ubuntu 20.04 x64

Linked PRs

• gh-106392: Fixed datetime UTC deprecation warnings use the name "datetime" inconsistently #106392 (#106392) #106405
• gh-106392: Fix inconsistency in deprecation warnings #106436
• [3.12] gh-106392: Fix inconsistency in deprecation warnings (GH-106436) #108792
• gh-106392: Fix inconsistency in deprecation warnings in datetime module #114761
• gh-106392: Fix consistency in pydatetime error messages #114764
• [3.12] gh-106392: Fix inconsistency in deprecation warnings in datetime module (GH-114761) #114767

Activity

1. wjandrea

   added

   type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

   on Jul 4, 2023
2. terryjreedy commented on Jul 4, 2023

   

   terryjreedy

   on Jul 4, 2023

   Member

   More actions

   The specific inconsistency is that datetime.now(datetime.UTC) uses datetime with two different meanings, first class then module. So the expression can never be correct regardless of the import. I agree with expanding the first datetime to what works with import datetime. This is what @hugovk did with the What'sNew entry. Users should then be able to figure out that the alternative is datetime.now(UTC), with the module label stripped off in both places after both objects are imported from the module.

   Reacted by William Andrea and louisboscher
3. hugovk commented on Jul 4, 2023

   

   hugovk

   on Jul 4, 2023

   Member

   More actions

   @wjandrea Thanks for the report, would you like to create a PR to update the deprecation warning text?
4. yctomwang

   added a commit that references this issue on Jul 4, 2023

   pythongh-106392: Fixed datetime UTC deprecation warnings use the name…

   e24344d
5. miss-islington

   added a commit that references this issue on Sep 1, 2023

   pythongh-106392: Fix inconsistency in deprecation warnings (pythonGH-…

   25b0bba
6. hauntsaninja

   added a commit that references this issue on Sep 1, 2023

   gh-106392: Fix inconsistency in deprecation warnings (#106436)

   d5c5d4b
7. Yhg1s

   added a commit that references this issue on Sep 2, 2023

   [3.12] gh-106392: Fix inconsistency in deprecation warnings (GH-106436)…

   b862c25
8. iritkatriel

   added

   stdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directory

   on Nov 26, 2023
9. serhiy-storchaka

   added a commit that references this issue on Jan 30, 2024

   pythongh-106392: Fix inconsistency in deprecation warnings in datetim…

   5da2081
10. serhiy-storchaka commented on Jan 30, 2024

    

    serhiy-storchaka

    on Jan 30, 2024

    Member

    More actions

    The C implementation was fixed in GH-108073. GH-106436 fixed the Python implementation incompletely, it left inconsistent references to methods at the beginning of warning messages.
11. hauntsaninja commented on Jan 30, 2024

    

    hauntsaninja

    on Jan 30, 2024

    Contributor

    More actions

    Ah sorry, I was mainly looking at the consistency between datetime.fromtimestamp and datetime.UTC needed to make that expression work, opened #114764
12. hauntsaninja

    added a commit that references this issue on Jan 30, 2024

    pythongh-106392: Fix consistency in pydatetime error messages

    a0ee17e
13. serhiy-storchaka

    added a commit that references this issue on Jan 30, 2024

    gh-106392: Fix inconsistency in deprecation warnings in datetime modu…

    dc4cd2c
14. miss-islington

    added a commit that references this issue on Jan 30, 2024

    pythongh-106392: Fix inconsistency in deprecation warnings in datetim…

    b5b543d
15. hauntsaninja

    added a commit that references this issue on Jan 31, 2024

    [3.12] gh-106392: Fix inconsistency in deprecation warnings in dateti…

    2e8417e
16. hauntsaninja

    closed this as completedon Jan 31, 2024
17. aisk

    added a commit that references this issue on Feb 11, 2024

    pythongh-106392: Fix inconsistency in deprecation warnings in datetim…

    013488b
18. Neecrownsmith

    added a commit that references this issue on Nov 22, 2024

    Update request_handler.py

    0520a33

Issue actions