[issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time

Changes by Chris Rebert : -- nosy: +cvrebert ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time

Alexander Belopolsky added the comment: > Please reopen. Please bring your case to python-ideas. All developers who commented on this issue agree that it is invalid. -- ___ Python tracker ___

[issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time

Andreas Pelme added the comment: I agree with Danilo and Shai -- this behavior very surprising. I deal with datetimes a lot, and this bug has bitten me a number of times. I cannot really think of a single case where "if timeobj:" is useful with the current behavior. It results in a check for "

[issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time

Shai Berger added the comment: Just got bit by this. Tim Peters said: """ It is odd, but really no odder than "zero values" of other types evaluating to false in Boolean contexts. """ I disagree. Midnight is not a "zero value", it is just a value. It does not have any special qualities analog

[issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time

Danilo Bargen added the comment: I disagree, I think this bug should be reopened and fixed. A use case that I just ran into: I'm using a Django form with time fields that aren't required, but that are only valid in combination (if there's a open time there has to be a close time). if not

[issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time

Changes by Éric Araujo : -- nosy: +eric.araujo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time

Lakin Wecker added the comment: Yeah - good point, and I agree. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time

Tim Peters added the comment: It is odd, but really no odder than "zero values" of other types evaluating to false in Boolean contexts ;-) Closing as "invalid". -- resolution: -> invalid status: open -> closed ___ Python tracker

[issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time

Lakin Wecker added the comment: 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. Tha

[issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time

Tim Peters added the comment: >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

[issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time

Alexander Belopolsky added the comment: This is by design. I don't have a reference, but I do remember this being discussed. Suggestions for improving the documentation are welcome. -- ___ Python tracker __

[issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time

Georg Brandl added the comment: BTW, "being a valid time" is not a good argument: 0, "" or False are all valid instances of their types. -- ___ Python tracker ___ _

[issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time

Georg Brandl added the comment: It must be by design -- someone has implemented a __bool__ (formerly __nonzero__) method; otherwise all objects would be true. -- nosy: +georg.brandl, lemburg ___ Python tracker __

[issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time

Lakin Wecker added the comment: Right. I've updated my code to be more correct: instead of: if not start_time: start_time = default_time it now reads: if start_time is None: start_time = default_time which operates correctly and works fine for my case, I just thought it was odd tha

[issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time

Changes by R. David Murray : -- nosy: +belopolsky ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.p

[issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time

R. David Murray added the comment: 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. -- nosy: +r.david.murray _

[issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time

Changes by Lakin Wecker : -- components: +Library (Lib) type: -> behavior ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time

Lakin Wecker added the comment: I'm updating the versions to the ones that I've actually tried it on - this is not an exhaustive search at this point. -- versions: +Python 2.6, Python 2.7 ___ Python tracker _

[issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time

New submission from Lakin Wecker : 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: import datetime if datetime.time(0,0,0): print "datetime.time(0,0,0) is not a bug!" els