Call to tzname() crashes when timezone name is None

Bug #1172926 reported by Nate Hart
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
dateutil
New
Undecided
Unassigned

Bug Description

Calling tzname() on a datetime object (in my case, the return value of dateutil.parser.parse()) crashes when the timezone name is None. The problem appears to be in tzname_in_python2() in tz.py, which returns the value of myfunc(*args, **kwargs).encode() to maintain consistency with Python 3 or something. The problem is when myfunc returns None, which throws "AttributeError: 'NoneType' object has no attribute 'encode'"

Storing the result of the call to myfunc and then checking if it's None before calling encode() appears to fix the problem. If it is None, then we can just return None, otherwise we can return result.encode() (more or less) safely.

I've personally changed my tz.py as follows because it's been preventing me from using a script I rely on:

- return myfunc(*args, **kwargs).encode()

+ result = myfunc(*args, **kwargs)
+ if not result:
+ return result
+ return result.encode()

Revision history for this message
srepmub (mark-dufour) wrote :

having the same problem with debian 8, where a new dateutil has become the default. monkey-patched around it for now, so it's not needed to modify tz.py:

+import dateutil.tz
+def tzname(self, dt):
+ return self._find_comp(dt).tzname
+dateutil.tz._tzicalvtz.tzname = tzname

(effectively disabling the python3-compat decorator)

Revision history for this message
Jelle van der Waa (jelle-vdwaa) wrote :

This bug seems to be fixed in the following Git commit. https://github.com/dateutil/dateutil/commit/5550481ed5a05f52e73a5f99c55720972d90dc6c

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.