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

Andrew Barnert abarnert at yahoo.com
Fri Mar 7 03:35:31 CET 2014


From: Tim Peters <tim.peters at gmail.com>

Sent: Thursday, March 6, 2014 6:16 PM


>>  Well, a time in Central is useless, but a time in CDT or CST is not, and 
> you can
>>  design a library that's smart enough to give you a CDT or CST (as 
> appropriate) time
>>  from a Central datetime.
> 
> Tell me how.  You have, in context, a Python `time` object with a
> "Central" tzinfo member.  That's all you get from the user.  
> You're
> given absolutely no information about day, month, or year.  What's
> your algorithm for implementing picking CDT or CST "as appropriate"?
> Note that we're NOT talking about datetime.datetime objects here.
> These are datetime.time objects.

Of course that's inherently ambiguous and therefore not solvable. If your app wants unambiguous times, it can't allow users to enter times in Central with no additional information.

But that's a separate problem from getting a CDT or CST time from a Central datetime (or from other problems, like handling a Central time that's known to be today). A datetime library could solve _that_ problem.

> This isn't a problem for datetime.datetime objects.  A "Central"
> tzinfo timeclass has no problem at all picking CDT or CST as
> appropriate given all the info in a datetime.datetime object.


Right, but if you get its tztime, you get a Central time, and no longer have the information that lets you use it as CDT or CST as appropriate. That is a problem—but, as I said before, it's probably not a problem in practice, and therefore probably not worth solving. (Again, I did solve it in a different timezone library, and never found a use for that feature.)


More information about the Python-ideas mailing list