On Mon, Aug 31, 2015 at 2:53 PM, Tim Peters <tim.peters@gmail.com> wrote:
But "continuing to never raise an exception" does not imply
"continuing to work as intended".  All such code needs to be carefully
audited in a PEP-495 world to ensure that the problem-case return
values work as intended with the old code and the new PEP 495 behavior
_if_ a 495-compliant tzinfo object is used.

My design goals with respect to aware datetime objects were

(1) objects with pre-PEP tzinfo should work exactly the same as they did before
(2) objects with post-PEP tzinfo may produce different results when used with pre-PEP code, but these differences should be limited to the problem cases (gaps and folds) where new behavior can be defended as a bug fix.

I find it unacceptable for a program that switched to post-PEP tzinfo to crash several years after that because it was not sufficiently well tested on problem times.

In most applications, confusing the first and the seconds 01:30 AM is a forgivable error.  Applications that cannot tolerate it should not use local times or should be carefully audited for PEP 495 compliance.  However, even applications that can tolerate a random choice between one 01:30AM and another usually cannot tolerate a server crash at 02:45 AM.