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

Tim Peters tim.peters at gmail.com
Fri Mar 7 02:36:29 CET 2014


[Donald Stufft]
> It's completely reasonable to attach a timezone to a time object.
>
> If I schedule an event in a calendar for Mar 7th, at 12pm Eastern, then
> absolutely that should be represented as a date time. But what if I want
> to schedule an event that occurs every day at 11:30AM EST? There's
> no date associated with it (except an infinite set, or the span of my life
> I suppose!) it's just 11:30AM EST.

That's a stretch, Donald.  Can you present an example of such an
event?  For someone living on the US East Coast, some days that event
would occur when their clock said 11:30AM, and on other days when it
occurred at - figure it out! - 10:30AM or 12:30PM?  Depending on
whether, in the real world, daylight time wasn't or was in effect.

In any case, you keep ignoring the context of what's written to
present some caricature to shoot down.  Here:

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

You didn't see the "most"?  Or the later repeated elaborations that
most tzinfo subclasses (in real life) _do_ attempt to model daylight
time?  An EST tzinfo subclass is a fixed-offset subclass, making no
attempt to model daylight time.  Those aren't the problem.  But
fixed-offset tzinfo subclasses are relatively rare.


More information about the Python-ideas mailing list