Repository navigation
RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True #58144
Description
| BPO | 13936 |
|---|
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:
assignee = None
closed_at = <Date 2014-03-20.23:02:51.235>
created_at = <Date 2012-02-03.20:43:16.223>
labels = ['3.8', 'type-feature', 'library']
title = 'RFE: change bool(datetime.time(0, 0, 0)) to evaluate as True'
updated_at = <Date 2021-11-04.14:30:38.369>
user = 'https://bugs.python.org/LakinWecker'bugs.python.org fields:
activity = <Date 2021-11-04.14:30:38.369>
actor = 'eryksun'
assignee = 'none'
closed = True
closed_date = <Date 2014-03-20.23:02:51.235>
closer = 'python-dev'
components = ['Library (Lib)']
creation = <Date 2012-02-03.20:43:16.223>
creator = 'Lakin.Wecker'
dependencies = []
files = []
hgrepos = []
issue_num = 13936
keywords = []
message_count = 51.0
messages = ['152556', '152557', '152558', '152559', '152560', '152561', '152562', '152563', '152564', '152565', '152567', '176475', '212732', '212738', '212743', '212771', '212777', '212778', '212779', '212782', '212783', '212784', '212785', '212786', '212787', '212788', '212789', '212790', '212791', '212798', '212799', '212801', '212806', '212807', '212871', '212873', '212877', '212879', '212880', '212881', '212883', '212884', '212886', '212892', '212904', '212911', '212915', '212916', '212921', '213434', '214299']
nosy_count = 0.0
nosy_names = []
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue13936'
versions = ['Python 3.8']
Activity
LakinWecker commentedon Feb 3, 2012
midnight is represented by datetime.time(0,0,0). However, this time (unlike all other valid times, including datetime.time(0,0,1)) evalutes to false in if conditions:
LakinWecker commentedon Feb 3, 2012
I'm updating the versions to the ones that I've actually tried it on - this is not an exhaustive search at this point.
bitdancer commentedon Feb 3, 2012
I don't think I would have ever thought of testing a datetime for its truth value. But the behavior you observe is consistent with the rest of Python: 0 is false.
I wonder if this is by design or by accident.
LakinWecker commentedon Feb 3, 2012
Right. I've updated my code to be more correct:
instead of:
it now reads:
which operates correctly and works fine for my case, I just thought it was odd that one time out of all of them evaluates to False. I too wonder if it's by design or not.
It's definitely not documented if it is by design.
birkenfeld commentedon Feb 3, 2012
It must be by design -- someone has implemented a __bool__ (formerly __nonzero__) method; otherwise all objects would be true.
birkenfeld commentedon Feb 3, 2012
BTW, "being a valid time" is not a good argument: 0, "" or False are all valid instances of their types.
abalkin commentedon Feb 3, 2012
This is by design. I don't have a reference, but I do remember this being discussed. Suggestions for improving the documentation are welcome.
tim-one commentedon Feb 3, 2012
From the docs, at:
http://docs.python.org/library/datetime.html#time-objects
"""
in Boolean contexts, a time object is considered to be true if and only if, after converting it to minutes and subtracting utcoffset() (or 0 if that’s None), the result is non-zero.
"""
LakinWecker commentedon Feb 3, 2012
Although I find it odd, you are all correct.
It is documented. (I don't know how I missed that when I read those docs looking for that exact documentation).
It is consistent with the rest of python.
Do I close this? Do you guys? I'm fine with closing it. Thanks and sorry for the noise.
tim-one commentedon Feb 3, 2012
It is odd, but really no odder than "zero values" of other types evaluating to false in Boolean contexts ;-) Closing as "invalid".
LakinWecker commentedon Feb 3, 2012
Yeah - good point, and I agree.
38 remaining items
tim-one commentedon Mar 7, 2014
[Nick]
aware_datetime_object.time() already returns a naive time object. The thorny question is what .timetz() should return - but if aware time objects _were_ deprecated, .timetz() itself would presumably be deprecated too.
The class constructor datetime.combine(date_object, time_object) makes it easy to combine any two date and time objects into a datetime object.
ethanfurman commentedon Mar 7, 2014
If no one else has gotten to this in the next six months or so, I will. :)
westleymartinez commentedon Mar 7, 2014
So is the plan to deprecate this in 3.5 and remove in 3.6? If so, the question is where should the deprecation be thrown?
BreamoreBoy commentedon Mar 8, 2014
There is no plan, other than the BDFL asking for a survey of what is happening with code that relies on this in the real world. FTR I'm completely against this change. I see no reason to change something that's been in use for maybe nine years and does what it's documented to do, based on somebody's expectations, failure to read the documents and buggy code. To me it would be a nail in the coffin of Python's very conservative, and to me extremely proper, view of maintaining backward compatibility.
dstufft commentedon Mar 8, 2014
To be specific, Guido said that if this 3.0 or 3.1 he'd be all for changing it, and the only question in his mind is how safe it is change. And that his intuition is that it's a nuisance feature and few people have actually relied on it and that he'd be OK with fixing (and breaking) it in 3.5, perhaps after a thorough search for how often the feature is actually relied on and how legitimate those uses are. (See the full response at https://mail.python.org/pipermail/python-ideas/2014-March/026785.html)
ncoghlan commentedon Mar 8, 2014
Mark, we kinda proved we're willing to break backwards compatibility in the name of improving usability when we embarked down the path of creating Python 3 and an associated transition plan from Python 2, rather than just continuing to develop Python 2.
Compared to some of the backwards compatibility breaks within the Python 2 series that were handled using the normal deprecating cycle (removing string exceptions, anyone?), this one would be truly trivial.
fandingo commentedon Mar 13, 2014
This behavior conflicts with the other major classes, datetime.date and datetime.datetime. The ostensible reason for this falsy behavior is that midnight represents a fundamental zero point. We should expect to see similar zero points that evaluate to False for the other two classes. However, they do not include such falsy behavior.
In [2]: bool(datetime.datetime(datetime.MINYEAR, 1, 1))
Out[2]: True
In [3]: bool(datetime.date(datetime.MINYEAR, 1, 1))
Out[3]: True
Why don't these classes have any sense of zero at their minimums?
datetime.time.__bool__ should be dropped if for nothing more than consistency.
python-dev commentedon Mar 20, 2014
New changeset 89aa669dcc61 by Benjamin Peterson in branch 'default':
remove the ability of datetime.time to be considered false (closes bpo-13936)
http://hg.python.org/cpython/rev/89aa669dcc61