datetime: .datetime-.datetime = .timedelta, .time-.time=TypeError ?

[Tim Peters]

[Christos TZOTZIOY Georgiou]
> Is there any reason for datetime.time subtraction not returning a
> datetime.timedelta object, just like datetime.datetime subtraction
> does?

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
> arithmetic.

What's wrong with using timedeltas?

>>> print timedelta(hours=3, minutes=15) - timedelta(hours=2, minutes=45)
0:30:00
>>>

> 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.