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!"
else:
    print "datetime.time(0,0,0) is a bug!"

if datetime.time(0,0,1):
    print "datetime.time(0,0,1) is not a bug!"
else:
    print "datetime.time(0,0,1) is a bug!"

I'm updating the versions to the ones that I've actually tried it on - this is not an exhaustive search at this point.

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.

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 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.

It must be by design -- someone has implemented a __bool__ (formerly __nonzero__) method; otherwise all objects would be true.

BTW, "being a valid time" is not a good argument: 0, "" or False are all valid instances of their types.

This is by design.  I don't have a reference, but I do remember this being discussed.  Suggestions for improving the documentation are welcome.

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.
"""

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.

It is odd, but really no odder than "zero values" of other types evaluating to false in Boolean contexts ;-)  Closing as "invalid".

Yeah - good point, and I agree.