> ...
> Another is tzinfo attribute of time. With time t,
> t.utcoffset() is kid of useless given that you
> cannot subtract it from t

Sure you can - but you have to write your code to do time arithmetic.  The time implementation does so under the covers when two "aware" time objects are compared:

    If both [time] comparands are aware and have
    different tzinfo members, the comparands are
    first adjusted by subtracting their UTC
    offsets (obtained from self.utcoffset()).


> and unless tzinfo is a fixed offset timezone, there
> is not enough information in t to compute the offset
> to begin with.

The docs _suggest_ that tzinfo.utcoffset(x, None) return the "standard" UTC offset, but in the end it's up to the tzinfo subclass designer to decide what they want an aware time object to return as an offset.

> Do you have any historical insight on this one?

History has nothing to do with it ;-)  There are several uses spelled out in the docs.  In addition to "aware" time comparison (mentioned above):

- Maintaining the datetime invariant

    d == datetime.combine(d.date(), d.timetz())

requires that an "aware" datetime's tzinfo member be attached to at least one of the date and time projections, and since raw dates are always "naive", that leaves the time projection as the only choice.

- Various string format operations use an "aware" time object's tzinfo member to incorporate time zone information - at least time.isoformat() and time.strftime().

That said, would have been fine by me if the "naive" versus "aware" distinction had been limited to datetime objects (i.e., if plain date and plain time objects had no notion of time zone).  If you need to know why time objects "really" support being aware, you'll have to ask Guido ;-)