Message 183137 - Python tracker

➜

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	<[email protected]>
In-reply-to

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

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.

History
Date	User	Action	Args
2013-02-27 11:06:59	ronaldoussoren	set	recipients: + ronaldoussoren, belopolsky, eric.smith, maker, petri.lehtinen, thezulk, joar, jbatista
2013-02-27 11:06:59	ronaldoussoren	set	messageid: <[email protected]>
2013-02-27 11:06:59	ronaldoussoren	link	issue17267 messages
2013-02-27 11:06:59	ronaldoussoren	create