[Datetime-SIG] Another round on error-checking

[Tim Peters]

[Alex]
>> This forum may not be inclusive enough for this.  People in this group know
>> too much!

[Stuart]
> Not all of us. I claim ignorance from not being able to follow this
> complete thread :)

Despite the Subject line, it's mostly been about consequences of PEP
495 ignoring `fold` altogether in some contexts, so as to have no
visible effect whatsoever in "naive time" (even for a datetime with a
zone).  Your brain cells have worked in the opposite direction so far,
to fight "naive time" tooth & nail inside pytz for aware datetimes.


> My naive assumptions would be that dt1 == dt2 implies that
> dt1.utctimetuple() == dt2.utctimetuple().

Yup!  Which is another reasonable expectation that could fail under
the current 495, when dt1 and dt2 share a zone.  If dt1 and dt2 are
the earlier and later of an ambiguous time in a common zone, they
differ only in their `fold` value.  Under 495, dt1 == dt2 would be
true anyway, but anything related to zone _conversion_ would see the
difference.  So .utctimetuple() would differ.  At a more basic level,
utcoffset() would also differ.

The proposed solution is to "simply" stop ignoring fold=1.  Then dt1
!= dt2 from the start, so no reasonable expectations are violated.
Except for someone working in naive time who somehow manages to force
`fold` to 1 anyway.  They may be surprised to see dt1 != dt2 in the
case above.  But only the first time they see it ;-)


> Which means the hash implementation can just be hash(dt.utctimetuple()).

Yup, it could be, provided 495 is changed to stop ignoring fold=1 for
intrazone comparisons.  It isn't (and won't be), because that would be
a poorer-quality hash implementation (nothing about the current
__hash__ should need to change):

-  .utctimetuple() throws away dt.microsecond, so hash() would produce massive
   collisions in some cases of regular inputs.

- There are faster ways of getting the effect of converting to UTC (including
  microseconds).  The actual implementation isn't documented, because it
  doesn't need to be ;-)