This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: add datetime.time.now() for consistency
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.5
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: belopolsky Nosy List: belopolsky, ezio.melotti, lemburg, r.david.murray, rhettinger, ronaldoussoren, techtonik
Priority: low Keywords: easy

Created on 2010-06-05 06:36 by techtonik, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (11)
msg107122 - (view) Author: anatoly techtonik (techtonik) Date: 2010-06-05 06:36
There is:
datetime.date.today()
datetime.datetime.today()
datetime.datetime.now([tz])

But no:
datetime.time.now([tz])
msg107166 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-06-06 00:11
Anatoly,

Didn't you just recently complain about the large number of functions in datetime module? (issue7584)

datetime.datetime.now().time() seems adequate to me.

What is your use case?
msg107191 - (view) Author: anatoly techtonik (techtonik) Date: 2010-06-06 08:19
> What is your use case?

>>> from datetime import now, today
>>> now()
datetime.time ...
>>> today()
datetime.date ...
msg107192 - (view) Author: anatoly techtonik (techtonik) Date: 2010-06-06 08:21
> Didn't you just recently complain about the large number of functions in datetime module?

About verbosity of datetime API to be exact, so it is a ratio of (API functions + required docs)/user code that makes required stuff done.
msg107331 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-06-08 17:59
Anatoly,

msg107191 belongs to issue8903, not here and it is not a use case, but rather a demonstration of how the proposed feature would work.

My question is why would an application need current time without current date?  I feel providing time.now() may lead so people to call date.today() and time.now() separately instead of datetime.now() leading to interesting bugs.

One think I would consider an improvement over the current situation, would be to rename date.today() to date.now().  There are too many ways to spell the same thing:

date.today()
datetime.today()
datetime.now().date()

and no easy way to write a "how long ago" function that would work for both date and datetime:

def ago(t):
    t.now() - t
msg118216 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-10-08 18:58
I need to correct myself: datetime.today() is not an alternative spelling of date.today(), but rather a function returning current datetime which subtly different from datetime.now().
msg162455 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2012-06-07 03:59
Closing for the lack of interest.  Proposed time.now() is already available as datetime.now().time().  No use case justifying any improvement in this area was presented.
msg162460 - (view) Author: anatoly techtonik (techtonik) Date: 2012-06-07 06:13
I'd say no consensus was reached due to lack of participation. My enthusiasm was killed by the issue8903 resolution.

My opinion is that:
   datetime.time.now()
is much better than:
   datetime.datetime.now().time()
msg162461 - (view) Author: anatoly techtonik (techtonik) Date: 2012-06-07 06:15
And I certainly don't agree with you that usability changes in API are not use cases.
msg221909 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2014-06-29 22:25
I would like to bring this issue to some conclusion.  Here is the summary:

Pro:

   datetime.time.now() is shorter than datetime.datetime.now().time()

Cons:

1.   date, time = datetime.date.today(), datetime.time.now() is attractive, but wrong.

2.   time detached from date is a strange object with limited support in datetime module (no timedelta arithmetics, issue 17267; tzinfo issues; etc.)

3.   No compelling use cases have been presented.
msg221946 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2014-06-30 07:21
For the reasons listed by others, marking this as closed/rejected.
History
Date User Action Args
2022-04-11 14:57:01adminsetgithub: 53148
2014-06-30 08:33:04berker.peksagsetstage: needs patch -> resolved
2014-06-30 07:21:50rhettingersetstatus: open -> closed

nosy: + rhettinger
messages: + msg221946

resolution: rejected
2014-06-29 22:25:01belopolskysetversions: + Python 3.5, - Python 3.4
nosy: + lemburg

messages: + msg221909

keywords: + easy
2014-03-07 15:58:23r.david.murraysetnosy: + r.david.murray
2013-06-08 17:39:05ezio.melottisetnosy: + ezio.melotti

versions: + Python 3.4, - Python 3.3
2013-06-05 22:23:44belopolskysetnosy: + ronaldoussoren
2013-06-05 22:23:37belopolskysetstatus: closed -> open
resolution: wont fix -> (no value)
2012-06-07 06:15:57techtoniksetmessages: + msg162461
2012-06-07 06:13:07techtoniksetmessages: + msg162460
2012-06-07 03:59:03belopolskysetstatus: open -> closed
resolution: postponed -> wont fix
messages: + msg162455
2010-12-01 18:46:55belopolskysetresolution: postponed
versions: + Python 3.3, - Python 3.2
2010-10-08 18:58:42belopolskysetstage: needs patch
type: enhancement
versions: - Python 3.1, Python 2.7, Python 3.3
2010-10-08 18:58:12belopolskysetmessages: + msg118216
2010-06-08 17:59:02belopolskysetmessages: + msg107331
2010-06-06 08:21:37techtoniksetmessages: + msg107192
2010-06-06 08:19:03techtoniksetmessages: + msg107191
2010-06-06 00:11:38belopolskysetpriority: normal -> low

nosy: + belopolsky
messages: + msg107166

assignee: belopolsky
2010-06-05 06:36:26techtonikcreate