datetime: .datetime-.datetime = .timedelta, .time-.time=TypeError ?
tim.one at comcast.net
Tue Sep 9 02:57:46 CEST 2003
[Christos TZOTZIOY Georgiou]
> Is there any reason for datetime.time subtraction not returning a
> datetime.timedelta object, just like datetime.datetime subtraction
Guido didn't want time objects participating in arithmetic because the
desired semantics are unclear. For example, if you allow
time1 - time2
to return a timedelta, then you'll also want to allow
time2 + timedelta
to return a time, and then you've got to make up rules for what happens when
adding spills over a midnight boundary. Should it "wrap around"? Raise
OverflowError? Guido didn't want to endure arguments about that.
Note that the analogous question for datetime objects is easy, because
there's a well-defined Beginning and End to the span of times datetime
objects can represent -- OverflowError is the obvious thing to get if you
try to compute a result spilling over those bounds. Try adding "a year" to
"midnight", though, and half the world will curse you if it raises an
exception, while the other half will curse you if it says "hmm -- still
midnight". A third half will whine about leap seconds <wink>.
> It doesn't feel good having to use dumb year, month, day
> arguments constructing datetime object when doing only time
What's wrong with using timedeltas?
>>> print timedelta(hours=3, minutes=15) - timedelta(hours=2, minutes=45)
> If there is no specific reason apart from lack of time (no pun), I'm
> willing to research it and write a patch (I haven't seen the code,
> but I believe it would be quite easy).
Selling it would be harder than writing it.
More information about the Python-list