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

[Tim Peters]

[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.