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 ronaldoussoren
Recipients belopolsky, eric.smith, jbatista, joar, maker, petri.lehtinen, ronaldoussoren, thezulk
Date 2013-02-27.11:06:59
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
datetime.time arithmetic cannot be timezone aware, as there is no associated date and hence you cannot possibly know if there it a DST transition.

I don't think this is a problem. Adding/removing time to a clock value has clear real-world semantics. Using the (naive) real world semantics is the best we can do and should generally give the expected answer.

As to cross-timezone comparisons: 

   time(0, tzinfo=est) - timedelta(hours=1) * 5 == time(0, tzinfo=utc)

fails because the LHS of '==' is a time in a different timezone than the value on the RHS. That's expected and correct.
Date User Action Args
2013-02-27 11:06:59ronaldoussorensetrecipients: + ronaldoussoren, belopolsky, eric.smith, maker, petri.lehtinen, thezulk, joar, jbatista
2013-02-27 11:06:59ronaldoussorensetmessageid: <>
2013-02-27 11:06:59ronaldoussorenlinkissue17267 messages
2013-02-27 11:06:59ronaldoussorencreate