[Datetime-SIG] Another round on error-checking
alexander.belopolsky at gmail.com
Tue Sep 1 19:00:19 CEST 2015
On Tue, Sep 1, 2015 at 12:36 PM, Carl Meyer <carl at oddbird.net> wrote:
> On 09/01/2015 10:12 AM, Guido van Rossum wrote:
> > I'm much less concerned about < being intransitive in edge cases. I also
> > don't particularly care about == following from the difference being
> > zero. Still, unless we're constrained by backward compatibility, I would
> > rather not add equivalence between *any* two datetimes whose tzinfo is
> > not the same object -- even if we can infer that they both must refer to
> > the same instant.
> I think the latter is certainly a backwards-compatibility requirement,
> since that equivalence is already very much present in the current
> implementation of datetime.__eq__ (well, datetime._cmp). If two
> datetimes have different tzinfo objects, they are converted to UTC and
> compared as instants.
> Following the same model would certainly imply that a fold=0 and fold=1
> datetime that are otherwise identical should not be considered equal,
> because they clearly represent different instants. I guess Alex's
> opposition to that is the (very small) chance of
> backwards-incompatibility, since currently it is possible to take two
> non-equal UTC datetimes an hour apart at a fold, convert them to local
> time, and then have them compare equal (since pre PEP 495 the conversion
> to local time during a fold loses information).
Here is an idea that I think may work: let's consider fold=1 instances as
if they have a different tzinfo instance from the other side in both
datetime subtractions and comparisons. This will be consistent with the
current stdlib and pytz work-arounds of representing "second" times using
fictitious fixed-offset timezones.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Datetime-SIG