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

[Mark Lawrence]

On 07/03/2014 11:13, Rob Cliffe wrote:
>
> 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

I disagree.  People here have stated that they use it.  I could use it 
if I wanted to, having been raised to do some strange things, as in read 
docs, so I'm firmly in favour of sticking with the status quo.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com