"tzinfo" objects can be hashable or not depending on the implementation, since "tzinfo" is an abstract base class.
In fact, `datetime.timezone.utc` and `datetime.timezone` objects are
*already* hashable.
There are several reasons why `dateutil` does has not made its tzinfo
objects hashable, and they depend on the particular time zone class:
1. `dateutil.tz.tzoffset` is the one that would be easiest to make
hashable, /but/ the hashing semantics may not be what you want them to
be, because tz.tzoffset("CST", timedelta(hours=-4)) ==
tz.tzoffset("EDT", timedelta(hours=-4)) returns True. As such those two
objects must have the same hash. tz.UTC is a special case of `tz.tzoffset`
2. All the data required to determine if two `dateutil.tz.tzlocal`
objects are "the same" is not even available to the Python layer, since
`tzlocal` dynamically queries the system time functions whenever you try
to resolve an offset with it. This leads to a host of subtle breakages
that it may not be possible to fix. It also means `tzlocal` objects are
kinda-sorta mutable in some ways.
3. `dateutil.tz.tzfile` and to a lesser extent `dateutil.tz.tzical` both
can have a fairly large amount of information backing them. A hash
operation that actually uses all this information might be expensive,
and one that doesn't use all the information might be wrong.
Other than `tz.tzlocal`, these are all fairly surmountable barriers, but
honestly I have never seen a particularly /good/ example of a reason to
hash tzinfo objects, so I have never felt that it should be a
particularly high priority for dateutil. Most of this is basically
off-topic for this list, though.
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/
