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 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:35belopolskysetrecipients: + belopolsky, skip.montanaro, ronaldoussoren, eric.smith, r.david.murray, maker, petri.lehtinen, francismb, thezulk, joar, jbatista
2014-03-07 19:46:35belopolskysetmessageid: <1394221595.23.0.540979305028.issue17267@psf.upfronthosting.co.za>
2014-03-07 19:46:35belopolskylinkissue17267 messages
2014-03-07 19:46:34belopolskycreate