[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 ;-) _______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
