[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