[Datetime-SIG] Another approach to 495's glitches
alexander.belopolsky at gmail.com
Sun Sep 6 22:53:41 CEST 2015
On Sun, Sep 6, 2015 at 2:58 PM, Tim Peters <tim.peters at gmail.com> wrote:
> > ...
> > Consider two aware datetimes that compare equal. The task is to prove
> > they have the same hash. The subtlety is that while __eq__ and
> > __hash__ both use a notion of "UTC equivalent", they're not always the
> > same notion. __eq__ always uses the given values of `fold`, while
> > __hash__ always forces fold=0.
> Which obviously ;-) suggests yet another, possibly cleaner, approach:
> have interzone subtraction, and all interzone comparisons, _also_
> force fold to 0 (instead of having only interzone __eq__ and __ne__
> special-case fold=1) .
I would not go that far. While interzone subtraction between arbitrary
zones is a rarely needed overkill, I find it useful to have subtraction
work between a local zone and UTC. For me, subtraction in this case is
similar to conversion. Fix the EPOCH and d = t - EPOCH together with t =
EPOCH + d gives you a bijection between times and timedeltas. From that,
you are one step away from various numeric time scales. For example (t -
datetime(1, 1, 1, tzinfo=timezone.utc)) // timedelta.resolution will give
you a bijection between datetimes and some range of integers. Thus if we
are going to "sell" fold as a way to implement conversions that "always
work", I think we should include these types of conversions as well.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Datetime-SIG