[Datetime-SIG] PEP 495: What's left to resolve

Alexander Belopolsky alexander.belopolsky at gmail.com
Sun Sep 13 05:42:10 CEST 2015


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 <
alexander.belopolsky at gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150912/21378517/attachment.html>


More information about the Datetime-SIG mailing list