Skip to content
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

Timezone conversion fails with current trunk (will become 0.24) #6

Closed
GoogleCodeExporter opened this issue Apr 19, 2015 · 9 comments
Closed

Comments

@GoogleCodeExporter
Copy link

What steps will reproduce the problem?
1. run mythcal

What is the expected output? What do you see instead?

Expected: successful execution
Actual: error message:

Traceback (most recent call last):
 File "./mythcal", line 109, in <module>
   recordings = get_recordings_from_backend()
 File "./mythcal", line 94, in get_recordings_from_backend
   upcoming = map(convert_program, upcoming)
 File "./mythcal", line 80, in convert_program
   "start": naive_local_time_to_naive_utc_time(prog.starttime),
 File "./mythcal", line 69, in naive_local_time_to_naive_utc_time
   aware_local_time = time_zone.localize(naive_local_time)
 File "/usr/lib/python2.6/site-packages/pytz-2009r-py2.6.egg/pytz/tzinfo.py",
line 251, in localize
ValueError: Not naive datetime (tzinfo is already set)

What version of the product are you using? On what operating system?
mythcal revision 19
MythTV Version   : 16542:26441M
MythTV Branch    : trunk
Network Protocol : 62

Please provide any additional information below.
I think it looks like the Python bindings have been updated such that the 
timezone information is returned. When we try to convert from a "naive" 
datetime to "local" time, it complains because the .tzinfo member is not None. 
I added some debug code and found that .tzinfo is something from the MythTV 
classes (sorry, I don't have that info handy).

I worked around it by explicitly setting .tzinfo = None, but then I get another 
error if I set my timezone to the correct value (in the config file). 
Interestingly, if I set it to some other timezones the script executes 
successfully (but then the recordings are some hours off in the google calendar)

I suspect the root of the problem is in the Python binding rewrite which has 
been done for the upcoming 0.24.

I would be happy to provide any additional information.

Original issue reported on code.google.com by memory...@gmail.com on 23 Sep 2010 at 2:03

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant