Message212898
| Author |
belopolsky |
| Recipients |
belopolsky, eric.smith, francismb, jbatista, joar, maker, petri.lehtinen, r.david.murray, ronaldoussoren, skip.montanaro, thezulk |
| Date |
2014年03月07日.19:46:34 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1394221595.23.0.540979305028.issue17267@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
I think the timezone related problems are a red herring. Aware datetime +/- timedelta arithmetics is naive - tzinfo is ignored in calculations and copied to the result:
http://hg.python.org/cpython/file/c83ce2a1841c/Lib/datetime.py#l1711
The utcoffset only will only come into play if we want to implement time - time -> timedelta, but this problem is already there in time comparisons:
http://hg.python.org/cpython/file/c83ce2a1841c/Lib/datetime.py#l1091
It is up to tzinfo subclass implementation writers to handle inability to compute utcoffset without date fields by raising an exception if necessary. It is perfectly fine for time - time to fail with an error coming from .utcoffset().
I also don't think the fate of #13936 has any bearing on this issue. As long as we are not trying to implement time + time -> time, we are not introducing any new notion of "zero time". |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2014年03月07日 19:46:35 | belopolsky | set | recipients:
+ belopolsky, skip.montanaro, ronaldoussoren, eric.smith, r.david.murray, maker, petri.lehtinen, francismb, thezulk, joar, jbatista |
| 2014年03月07日 19:46:35 | belopolsky | set | messageid: <1394221595.23.0.540979305028.issue17267@psf.upfronthosting.co.za> |
| 2014年03月07日 19:46:35 | belopolsky | link | issue17267 messages |
| 2014年03月07日 19:46:34 | belopolsky | create |
|