> 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). Ronald
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4