[Datetime-SIG] Another round on error-checking
tim.peters at gmail.com
Wed Sep 2 18:33:59 CEST 2015
>> This forum may not be inclusive enough for this. People in this group know
>> too much!
> 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 ;-)
More information about the Datetime-SIG