While I agree this is surprising behavior and I wouldn't design an API this way, it is documented behavior. From the docs:
"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"
Changing at this point would possibly break code that relied on documented library behavior. That's not a responsible thing to do.
I'm not sure what that is supposed to mean in this context. Testing for "is not None" is more explicit and avoids the trap being discussed. I don't know how the second sentence applies, maybe "if timeval:" is simpler?
BTW, do you know the original author of the Zen of Python has posted to this very dicussion (while also being the orginal author of said module):
"Simplicity" is not measured in terms of key presses or characters.
The "if timeval:" case may contain fewer characters, but it's less explicit. Being less explicit opens it up to greater ambiguity. Ambiguity is a form of complexity. Complexity is the opposite of simplicity.
The explicit "is not None" check may require more typing, but it's far more explicit and exact. That means it's much less ambiguous, and thus less complex, and thus exhibits greater simplicity.
I really have to wonder if there is actually any code out there that relies on it. Even given Python's great popularity, I would not be surprised if fixing this broke nothing at all.
"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"
Changing at this point would possibly break code that relied on documented library behavior. That's not a responsible thing to do.