> On 27 Jul 2015, at 04:04, Tim Peters <tim.pet...@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). Ronald _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
