Message183137
| 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 |
<1361963219.56.0.43023852676.issue17267@psf.upfronthosting.co.za> |
| 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. |
|