In a sibling response, I responded as to why hashing tzinfo objects may be a bad idea in dateutil, but one thing that I think is on topic for this list that was brought up in this comment on the dateutil tracker <https://github.com/dateutil/dateutil/issues/792#issuecomment-409701152>, which is that as it stands now, datetime.timezone object equality (and hashing) both ignore the offset name, which means:
>>> timezone(timedelta(hours=-4), "EDT") == timezone(timedelta(hours=-4), "CST") True It also means any 0-offset zone is equal to timezone.utc. I find at least the first behavior somewhat surprising, as I consider the offset to be only one facet of the tzinfo, even for fixed-offset zones. For the (possibly dubious) use case mentioned in dateutil issue #792 linked in the original post of storing `tzoffset` objects in a set, I think this will be extra surprising, since it will collapse all time zones with the same offset into one entry. I think it might be asking a lot to actually make a possibly backwards-incompatible change to fix this if this is not a desirable change, but for those of us designing our own time zone offsets, I am curious to know what the reasoning for this was, and if it is still seen as desirable. Best, Paul On 4/15/19 7:51 PM, Brock Mendel wrote: > This is tied in with the equality semantics of these objects, has come > up here, in the dateutil tracker, and in pandas: > > https://mail.python.org/archives/list/[email protected]/thread/45P3EXY3OJM56MJJH57VJ7NZEBXG7HG4 > <https://mail.python.org/archives/list/[email protected]/thread/45P3EXY3OJM56MJJH57VJ7NZEBXG7HG4/> > / > <https://mail.python.org/archives/list/[email protected]/thread/45P3EXY3OJM56MJJH57VJ7NZEBXG7HG4/>https://github.com/dateutil/dateutil/issues/835 > https://github.com/dateutil/dateutil/issues/792 > https://github.com/pandas-dev/pandas/pull/24006#discussion_r238483612 > > My understanding is that hashing cannot be implemented until/unless > equality is changed. Is that accurate? Is there a compelling reason > for these _not_ to be hashable? > > _______________________________________________ > Datetime-SIG mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/datetime-sig.python.org/ > The PSF Code of Conduct applies to this mailing list: > https://www.python.org/psf/codeofconduct/
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Datetime-SIG mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/datetime-sig.python.org/ The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
