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

[Jason Killen]

Jason Killen  added the comment:

Yep I wasn't seeing the forest for the trees.  Thanks for clearing that up.  
I'll swoop back in and see what I can do.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Paul Ganssle]

Paul Ganssle  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mike]

Mike  added the comment:

Ok. I'll file a bug on pytz. Thanks!

On Sat, Nov 16, 2019 at 11:18 PM Karthikeyan Singaravelan <
rep...@bugs.python.org> wrote:

>
> Change by Karthikeyan Singaravelan :
>
>
> --
> nosy: +p-ganssle
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +p-ganssle

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Jason Killen]

Jason Killen  added the comment:

This appears to be a bug in pytz which as far as I can tell is not part of the 
"standard" lib, at least it's not in Lib.

Running this example which does not use pytz:
from datetime import timedelta, datetime, tzinfo, timezone, time

# stole this from the docs, and beat it up a bit
class KabulTz(tzinfo):
def utcoffset(self, dt):
return timedelta(hours=4, minutes=30)

def fromutc(self, dt):
# Follow same validations as in datetime.tzinfo
if not isinstance(dt, datetime):
raise TypeError("fromutc() requires a datetime argument")
if dt.tzinfo is not self:
raise ValueError("dt.tzinfo is not self")

return dt + timedelta(hours=4)

def dst(self, dt):
# Kabul does not observe daylight saving time.
return timedelta(0)

def tzname(self, dt):
return "+04"

tzaware_time2 = time(7,30,tzinfo=timezone.utc)
tzaware_time1 = time(7,30,tzinfo=KabulTz())

tzunaware_time = time(7, 30)

tzaware_time1 < tzaware_time2

I get no error.

When I use your example I notice that utcoffset in pytz/tzinfo.py returns None 
for the Denver example but for the UTC object returns ZERO which happens to be 
timedelta(0) which seems correct.  It's weird to me that pytz is returning None 
in the Denver case because I think what it should return is right there in 
self._utcoffset.

More info: It looks like pytz isn't handling the fact that it's a time only 
type.  `dt` appears to be a datetime when utcoffset is called from a datetime.

--
nosy: +Jason.Killen

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mike]

New submission from Mike :

import pytz
import datetime

tzaware_time1 = datetime.time(7,30,tzinfo=pytz.timezone("America/Denver"))
tzaware_time2 = datetime.time(7,30,tzinfo=pytz.utc)

tzunaware_time = datetime.time(7, 30)

# This fails with exception: TypeError: can't compare offset-naive and 
offset-aware times
# even though both ARE tz aware.
tzaware_time1 < tzaware_time2

# This does NOT raise an exception and should since one is aware and one isn't.
tzunaware_time < tzaware_time1

--
messages: 356673
nosy: epicadv
priority: normal
severity: normal
status: open
title: Comparing datetime.time objects incorrect for TZ aware and unaware
versions: Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com