[Datetime-SIG] Another approach to 495's glitches

[Carl Meyer]

On 09/06/2015 02:53 PM, Alexander Belopolsky wrote:
> On Sun, Sep 6, 2015 at 2:58 PM, Tim Peters <tim.peters at gmail.com
> <mailto:tim.peters at gmail.com>> wrote:
> 
>     [Tim]
>     > ...
>     > 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.

FWIW, Tim's latest proposal (either variant) resolves all my concerns
with PEP 495 (as I explained at greater length in the "Timeline
arithmetic" thread).

Fundamentally I don't care between these two variants (because the
difference between them only impacts interzone operations, and my
general advice on those going forward would be "don't use them").

Carl

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150906/8a45303d/attachment.sig>