Closed 9432cd65-9f88-4bc6-8ad6-72e5ab1c730d closed 10 years ago
There is: datetime.date.today() datetime.datetime.today() datetime.datetime.now([tz])
But no: datetime.time.now([tz])
Anatoly,
Didn't you just recently complain about the large number of functions in datetime module? (bpo-7584)
datetime.datetime.now().time() seems adequate to me.
What is your use case?
What is your use case?
>>> from datetime import now, today
>>> now()
datetime.time ...
>>> today()
datetime.date ...
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.
Anatoly,
msg107191 belongs to bpo-8903, 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
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().
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.
I'd say no consensus was reached due to lack of participation. My enthusiasm was killed by the bpo-8903 resolution.
My opinion is that: datetime.time.now() is much better than: datetime.datetime.now().time()
And I certainly don't agree with you that usability changes in API are not use cases.
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:
date, time = datetime.date.today(), datetime.time.now() is attractive, but wrong.
time detached from date is a strange object with limited support in datetime module (no timedelta arithmetics, bpo-17267; tzinfo issues; etc.)
No compelling use cases have been presented.
For the reasons listed by others, marking this as closed/rejected.
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields: ```python assignee = 'https://github.com/abalkin' closed_at =
created_at =
labels = ['easy', 'type-feature', 'library']
title = 'add datetime.time.now() for consistency'
updated_at =
user = 'https://bugs.python.org/techtonik'
```
bugs.python.org fields:
```python
activity =
actor = 'berker.peksag'
assignee = 'belopolsky'
closed = True
closed_date =
closer = 'rhettinger'
components = ['Library (Lib)']
creation =
creator = 'techtonik'
dependencies = []
files = []
hgrepos = []
issue_num = 8902
keywords = ['easy']
message_count = 11.0
messages = ['107122', '107166', '107191', '107192', '107331', '118216', '162455', '162460', '162461', '221909', '221946']
nosy_count = 7.0
nosy_names = ['lemburg', 'rhettinger', 'ronaldoussoren', 'belopolsky', 'techtonik', 'ezio.melotti', 'r.david.murray']
pr_nums = []
priority = 'low'
resolution = 'rejected'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue8902'
versions = ['Python 3.5']
```