Home Original page

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

Tim Peters tim.peters at gmail.com
Fri Mar 7 02:51:48 CET 2014 
[Donald Stufft]
>> 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.

[Chris Angelico <rosuav at gmail.com>]
> Repeating events need their own handling. Maybe it's safe to use
> 11:30AM local time, but what if you specify 1:30AM America/New_York?
> How can you render that onto a calendar? There'll be times when it
> breaks - one day a year when it's ambiguous, and one day a year when
> it doesn't exist. How can you work with a time that might not exist?

Filling in the blanks, I presume that Donald's "EST" is what the docs
call a "fixed-offset" tzinfo subclass:  it represents a fixed offset
from UTC.  It's what a US East Coast clock would look like if the
idiotic ;-) "daylight saving" rules were repealed, and the East Coast
stayed on "standard" time forever.

Such classes are utterly problem-free.  No ambiguities, no clock
leaping ahead or leaping back, no "missing" hours, no "duplicate"
hours, they just march on forever in perfect lockstep with UTC.

Alas, such classes are also rare.
More information about the Python-ideas mailing list