Has this already been discussed elsewhere?

No response given

This needs discussing at https://discuss.python.org/c/ideas/6 first, but it is unlikely to be changed, to maintain backwards compatibility.

I recommend using this pattern to avoid ambiguity:

import datetime as dt

current_time = dt.datetime.now().time()
nine_thirty = dt.time(9, 30)
status = current_time > nine_thirty

(typed on phone, so there may be a typo)

See https://adamj.eu/tech/2019/09/12/how-i-import-pythons-datetime-module/

datetime.time is not a module - it's a class:

>>> import datetime
>>> datetime.time
<class 'datetime.time'>

Because the time module of datetime has the same name as the time module of the standard library

Yes, this name clashes with the time module. It happens in other places of the stdlib as well. E.g. math.log and cmath.log.

Renaming (how?) will be a backward compatibility break. Why do you think it worth? To avoid conflict you might create alias like from datetime import time as badtime.

You can close it, but you will still encounter many people like me who provide feedback on this issue in the future, just like the one in your link. This shows that the problem is not root cause, it is just a compromise.

Maybe it is a software design issue.
For example,

from datetime import time, date # It is ok but it will conflict with the standard library 'import time'
t = time(9, 30)
d = date(2025, 12, 1)

or

import datetime # ok
t = datetime.time(9, 30)
d = datetime.date(2025, 12, 1)

both of the above methods are fine, but the one below is incorrect.

from datetime import datetime # error
t = datetime.time(9, 30)
d = datetime.date(2025, 12, 1)

A good design can avoid this confusion. Additionally, time() is sometimes a get property and sometimes a constructor. Going back to the beginning, what I meant was that constructing date or time objects was originally a very simple scenario, but it caused so much trouble...... Thanks.

As mentioned, please discuss this at discuss.python.org/c/ideas/6 first. Thanks.