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.