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

Rob Cliffe rob.cliffe at btinternet.com
Fri Mar 7 12:13:29 CET 2014


On 07/03/2014 02:16, Tim Peters wrote:
> [Tim]
>>> No, it's bizarre to attach a timezone to a time object because most
>>> tzinfo subclasses don't - and can't - know what to return for the UTC
>>> offset in the absence of - at least - month and day info too.  Hour,
>>> minute, second and microsecond aren't usually enough to determine
>>> whether "daylight time" is in effect, and most tzinfo subclasses do
>>> attempt to model daylight time.  And because daylight time is a
>>> political conceit, most tzinfo subclasses also need year info.  That
>>> has nothing to do with whether times are viewed abstractly,
>>> concretely, etc - it has to do with that time zones generally aren't
>>> _defined_ in terms of isolated time-of-day info.  It's 7:13 PM in US
>>> Central.  Is that daylight (CDT) or standard (CST) time?  It's
>>> impossible to answer.  What's the corresponding UTC time?  Ditto.
> [Andrew Barnert <abarnert at yahoo.com>]
>> 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.
>
> 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.
> _______________________________________________
>
Guys, please.  This discussion is getting increasingly esoteric and has 
become irrelevant to the original proposition.
What it does show is that the current truthy behaviour of time objects 
is incomprehensible to the average programmer.  And therefore useless to 
her.
Rob Cliffe


More information about the Python-ideas mailing list