[issue38812] Comparing datetime.time objects incorrect for TZ aware and unaware

Paul Ganssle report at bugs.python.org
Sun Nov 17 10:07:41 EST 2019


Paul Ganssle <p.ganssle at gmail.com> added the comment:

I do not think this is a bug in pytz, but if it's a bug in Python it's one in reporting what the error is.

The issue is that the time zone offset for "rules-based zones" like America/Denver (i.e. most time zones) is *undefined* for bare times, because the offset that apply depends on the *date* and the *time*.

The documentation for `tzinfo.utcoffset` specifies that if the offset is unknown, a time zone offset should return None: https://docs.python.org/3/library/datetime.html#datetime.tzinfo.utcoffset

The documentation for determining whether an object is aware or naive also specifies that if utcoffset() returns `None`, the object is naive (even if tzinfo is not None): https://docs.python.org/3/library/datetime.html#determining-if-an-object-is-aware-or-naive

So basically, everyone is doing the right thing except the person who attached this `pytz` time zone to a time object (as a side note, it may be worth reading this blog post that explains why the way this time zone is attached to the `time` object is incorrect: https://blog.ganssle.io/articles/2018/03/pytz-fastest-footgun.html).

That said, we may be able to improve the error message raised here by distinguishing between the case where there's no `tzinfo` at all and the case where `utcoffset()` returns `None`. I think we can change the exception message to have a helpful hint like, "cannot compare offset-naive and offset-aware times; one of the operands is offset-naive because its offset is undefined."

We could possibly be even more specific.

----------
components: +Library (Lib)
versions: +Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38812>
_______________________________________


More information about the Python-bugs-list mailing list