I'm going to kind of echo Paul Moore's argument here, and say this entire discussion is missing the forest for the trees. Duck typing exists so you can code fr

I'm going to kind of echo Paul Moore's argument here, and say this entire discussion is missing the forest for the trees. Duck typing exists so you can code freely and with expression, but the obvious converse of that is it allows you to shoot yourself in the foot. From my POV it seems like people here are complaining that when they point the gun at their foot it seems to randomly go off when testing date values, and the simple answer to that would be "Well, then don't point the gun at your foot!" IM(not so)HO the Zen of Python operates as an excellent counterbalance to the kind of pitfalls Python can lead you to, the "false midnight" being a wonderful example of said pitfalls that is completely removed when following PEP 20. >> "Explicit is better than implicit." Dates IRL cannot be false, so checking for falsiness is ambiguous. Perhaps you meant to check if it was "not None". And look! The wonderful expressiveness of Python allows such a thing! `if timeobj:` is a snippet that has some heavy assumptions behind it, and if I'm reading your code this is very much not explicit to me what you're trying to do. >> "Simple is better than complex." Dealing with dates/time will always be nasty business. Let's not add to that, and make things as simple as possible. If you are explicitly checking for midnight, perhaps a constant value set to `datetime.time(0,0,0)` would be useful for a conditional. >> "There should be one-- and preferably only one --obvious way to do it." There are Pythonic ways to check for `None` and there are ways to compare date time objects. The key word for me here is "obvious", since, again, the idea of a date having a boolean value is entirely foreign to the real world, and more or less a shortcut found only in computing. Don't create an edge case that you don't have to. Now granted, the stated behavior can definitely be seen to also violate PEP 20, but simply avoiding this entire issue renders that point moot. tl;dr: People complaining about unexpected results when writing bad Python code are barking up the wrong tree. Perhaps you should try a different language, or learn to code in a more Pythonic style? Both of these avenues would be much more profitable not only in the short term, but also the long term.