On Mon, Aug 31, 2015 at 2:53 PM, Tim Peters <[email protected]> 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.
_______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
