[Python-Dev] Status on PEP-431 Timezones

Ronald Oussoren ronaldoussoren at mac.com
Mon Jul 27 16:57:16 CEST 2015

> On 27 Jul 2015, at 04:04, Tim Peters <tim.peters at gmail.com> wrote:
>> As an example, consider an alarm clock. I want it to go off at 7am
>> each morning. I'd feel completely justified in writing tomorrows_alarm
>> = todays_alarm + timedelta(days=1).
>> If the time changes to DST overnight, I still want the alarm to go off
>> at 7am. Even though +1 day is in this case actually + 25 (or is it
>> 23?) hours. That's the current semantics.
> There was a long list of use cases coming to the same conclusion.  The
> current arithmetic allows uniform patterns in local time to be coded
> in uniform, straightforward ways.  Indeed, in "the obvious" ways.  The
> alternative behavior favors uniform patterns in UTC, but who cares?
> ;-)  Few local clocks show UTC.  Trying to code uniform local-time
> behaviors using "aware arithmetic" (which is uniform in UTC. but may
> be "lumpy" in local time) can be a nightmare.
> The canonical counterexample is a nuclear reactor that needs to be
> vented every 24 hours.  To which the canonical rejoinder is that the
> programmer in charge of that system is criminally incompetent if
> they're using _any_ notion of time other than UTC ;-)

IMHO “+ 1 days” and “+ 24 hours” are two different things.  Date 
arithmetic is full of messy things like that.  “+ 1 month” is another
example of that (which the datetime module punts completely
and can be a source of endless bikeshidding).


More information about the Python-Dev mailing list