[Datetime-SIG] Another round on error-checking
carl at oddbird.net
Tue Sep 1 18:36:05 CEST 2015
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).
Personally I think that latter backwards-incompatibility would be a
reasonable bugfix to make the existing semantics of datetime equality
consistent in folds. Though I suppose it's possible someone somewhere is
relying on that as a very strange way of detecting a fold?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: OpenPGP digital signature
More information about the Datetime-SIG