On Mon, Aug 31, 2015 at 1:58 PM, Tim Peters <tim.peters@gmail.com> wrote:

PEP 495 specifies resolving such cases by magic, in essentially arbitrary (from the user's point of view) ways. This isn't for backward compatibility, because 495-compliant tzinfos don't currently exist

.. but tzinfo.fromutc() [1] does exist and the first thing happening in that code is an unguarded call to utcoffset() on a UTC datetime with a transplanted tzinfo. [2] A trick like this have been valid in datetime since its introduction and has been used in numerous places since. You know that with a little effort universal .fromutc() can be rewritten to be PEP 495 compliant. If you think allowing datetime.utcoffset() to raise an exception is an option, let's first see how one can rewrite universal tzinfo.fromutc() for that design. Even though I don't think reusing a universal .fromutc() is a good option for tzinfo implementers, it gives an example of simple but non-trivial datetime manipulation code which PEP 495 is designed not to break. [1]: https://hg.python.org/cpython/file/v3.5.0rc2/Lib/datetime.py#l957 [2]: https://hg.python.org/cpython/file/v3.5.0rc2/Lib/datetime.py#l965