[Python-ideas] Please reconsider the Boolean evaluation of midnight

[Andrew Barnert]

On Mar 6, 2014, at 3:13, Stefan Krah <stefan at bytereef.org> wrote:

> Antoine Pitrou <solipsis at ...> writes:
>> It is not a coincidence, IMO, that the three persons arguing that the 
>> current behaviour is reasonable are implementors of datetime modules: 
>> you, Tim and Alexander. All other people find the behaviour baffling.
> 
> Not all. :)  I think viewing midnight as (unix_time % 86400) is
> quite reasonable.

I agree with Stefan here. Treating midnight as zero is not at all baffling. There's a reason modular arithmetic is taught to kids as "clock arithmetic", after all. And it's not unheard of for other languages/libraries/apps to treat midnight as a 0, or even to use it as a null time. Someone else already mentioned that many RDBMS's don't have a separate date type and store dates as datetimes with midnight time. IEEE datetimes also do this--leaving off any trailing component is equivalent to having 0's there.

And this isn't some experts-only thing. Novices regularly ask why we need the date class when a datetime with 0 time does the same thing--often because that's what their first language did, but sometimes just as an a priori expectation. 


On the other hand, the alternative isn't baffling either. Unlike, say, Oracle, Python has separate types for date, time, and datetime, so we don't need to use 0 for "n/a", and it has tz-aware values for all three types, making midnight much less special, and it doesn't have modular arithmetic on times (and timedeltas), etc.

So honestly, if handed the Python time class, I wouldn't know whether to expect midnight to be treated as 0 (and therefore falsey) or not, and would have to read the docs rather than guessing.

When a choice really is arbitrary like this, "it does what it's documented to do" is the only notion of correct that makes sense. 

(As a disclaimer, I have implemented datetime libraries for C and C++, but not for Python.)