I have now rewritten the "Temporal Arithmetic" section of the PEP to reflect "Solution 3."
Hg commit: https://hg.python.org/peps/rev/3dc0382326de Rendered PEP section: https://www.python.org/dev/peps/pep-0495/#temporal-arithmetic-and-comparison-operators In addition to a general review of the rewritten section, I would like to ask the group to comment on the following part specifically: "The result of addition (subtraction) of a timedelta to (from) a datetime will always have fold set to 0 even if the original datetime instance had fold=1." There are two "obvious" choices here: (t + d).fold == 0 and (t + d).fold == t.fold. My original motivation for the rule above was to minimize the chances that a user would ever see a fold=1 instance. However, I now think that preserving the value of fold may be a better option. For example, an application that needs to iterate over minutes in the repeated hour will not need to adjust the fold attribute after each addition. On the other hand, there is little harm from accidentally "leaking" fold=1 into the regular zone where fold value makes no difference. On Wed, Sep 9, 2015 at 11:44 AM, Alexander Belopolsky < [email protected]> wrote: >> > >Solution 1: Make t1 > t0. >> >> Solution 2: Leave t1 == t0, but make t1 != u1. >> >> >> Solution 3: Leave t1 == t0, but make *both* t0 != u0 and t1 != u1 if t0.utcoffset() != t1.utcoffset(). > > > I've implemented [1] Solution 3 in my Github fork. > > [1]: https://github.com/abalkin/cpython/commit/aac301abe89cad2d65633df98764e5b5704f7629
_______________________________________________ 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/
