This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author tim.peters
Recipients amaury.forgeotdarc, belopolsky, brett.cannon, brian.curtin, daniel.urban, giampaolo.rodola, lemburg, mark.dickinson, pitrou, r.david.murray, rhettinger, techtonik, tim.peters, vstinner
Date 2010-07-05.02:14:04
SpamBayes Score 0.00639322
Marked as misclassified No
Message-id <>
> ...
> 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.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 ;-)
Date User Action Args
2010-07-05 02:14:07tim.peterssetrecipients: + tim.peters, lemburg, brett.cannon, rhettinger, amaury.forgeotdarc, mark.dickinson, belopolsky, pitrou, vstinner, techtonik, giampaolo.rodola, r.david.murray, brian.curtin, daniel.urban
2010-07-05 02:14:06tim.peterssetmessageid: <>
2010-07-05 02:14:05tim.peterslinkissue7989 messages
2010-07-05 02:14:04tim.peterscreate