[Datetime-SIG] Another round on error-checking
alexander.belopolsky at gmail.com
Mon Aug 31 23:29:49 CEST 2015
On Mon, Aug 31, 2015 at 2:53 PM, Tim Peters <tim.peters at 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
(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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Datetime-SIG