When implementing PEP495 for dateutil, I ran across an issue that is related to this: https://www.python.org/dev/peps/pep-0495/#aware-datetime-equality-comparison I'm not sure I understand the reasoning for ambiguous times in inter-zone comparisons comparing as unequal, but I'll take as accepted that this is going to be the assumption, going forward. However, I don't understand why it must be the case that something is considered an "inter-zone" comparison whenever `t.tzinfo is not s.tzinfo`. What is the objection to using `t.tzinfo != s.tzinfo` as the criterion? In general these will be equivalent, but using __eq__ allows time zone providers to determine what is considered an "inter-zone" comparison. One issue is that this actually breaks backwards compatibility of the language, because as far as I can tell there's no way for me to provide a (backwards-compatible) tzinfo class that will preserve this behavior on python versions <= 3.6. Consider: ``` from datetime import datetime from dateutil import tz NYC = tz.gettz('America/New_York') ET = tz.gettz('US/Eastern') dt = datetime(2011, 11, 6, 5, 30, tzinfo=tz.tzutc()) # This is 2011-11-06 01:30 EDT-4 dt_edt = dt.astimezone(ET) dt_nyc = dt.astimezone(NYC) print(dt_nyc == dt_edt) ``` In Python 3.5 that will return True, in Python 3.6 it will return False, even though 'US/Eastern' and 'America/New_York' are the same zone. In this case, I might be able to enforce that these time zones are singletons so that `is` always returns True (though this may have other negative consequences for utility), but even that solution would fall apart for things like `tzrange` and `tzstr`, where you can know that the `dt.utcoffset()`s are going to be identical for ALL values of `dt`, but you can't force the objects to be identical.