-
-
Notifications
You must be signed in to change notification settings - Fork 175
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TypeError: bad tzinfo state arg
when encoding/decoding timezone-aware datetimes
#133
Comments
Small hack while jsonpickle#133 is resolved.
Seems like this hasn't been fixed yet in 1.2? Is this the only workaround? |
Hi all, got some new info. installed version: First, here is a simple script of how to reproduce the issue fast and easy. import datetime
from pprint import pprint
import jsonpickle
import pytz
d1 = datetime.datetime(2020, 6, 6, 6, 6, 6, 6, tzinfo=pytz.UTC)
d2 = datetime.datetime(2020, 6, 6, 6, 6, 6, 6, tzinfo=pytz.UTC)
l = [d1, d2]
encoded_list = jsonpickle.encode(l, make_refs=False)
pprint(encoded_list)
decoded_list = jsonpickle.decode(encoded_list) I have been doing some investigation, the issue happens only when As per my understanding when flatten is called for pytz.UTC object since it's a singleton it has the same ID and it will be in objs so _in_cycle will return true and My proposed solution is when make_refs is False, self._objs should not be populated. |
This is another issue that is solved by the proposed solution in #338 -- please give it a try. I added unit tests with pytz.UTC tzinfo as part of that change to verify that it's working as intended. The changes are currently in the |
Merged and fixed 😺 |
Here's the Gist
I'm using Django (and I have
pytz
installed, and Django uses it) to parse datetime values with timezone information. The problem appears to be when encoding these values and then decoding them in another Python process (like a background queue).This is an example of what I'm pickling. The
TEST_DATES_STR
is not the actual value I'm saving;parse_datetime
lives indjango.utils.dateparse
, and that code it's already included in the gist, so there's no need to install Django to reproduce the bug:Basically we have
encode.py
(first invocation) which simply does:and we have
decode.py
that simply does:The traceback (execution never reaches the
assert
statement):This is while
jsonpickle
is deserializing the second datetime value (the first value is properly deserialized). I tried usingmake_refs=False
when callingjsonpickle.dumps
, but no dice. I tracked down the bug to this method (jsonpickle/handlers.py:166
):Where the
params
tuple ends up with the last item being a_Proxy
object with theinstance
attribute set to None. If we add these lines just before thereturn
statement:Of course the
TypeError
is gone, but it will return the correctdatetime
but without timezone information.The text was updated successfully, but these errors were encountered: