Timezone conversion fails with current trunk (will become 0.24)

[GoogleCodeExporter]

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

[GoogleCodeExporter]

Times with timezone information are 'aware' times, whereas times without 
timezone information are 'naive'.

It sounds like MythTV is now returning aware local times, instead of naive 
local times. If that's correct, then the first step in 
naive_local_time_to_naive_utc_time - converting a naive local time to an aware 
local time - is unnecessary.

Please revert back to the original copy of mythcal (r19), and try changing line 
69 from:

  aware_local_time = time_zone.localize(naive_local_time)

to:

  aware_local_time = naive_local_time

Thanks!

Original comment by richardfearn on 30 Dec 2010 at 12:51

• Changed state: Accepted

[GoogleCodeExporter]

Thanks for the suggestion. I tried making the change, but I still get an error:

$ ./mythcal
Traceback (most recent call last):
  File "./mythcal", line 112, in <module>
    recordings = get_recordings_from_backend()
  File "./mythcal", line 97, in get_recordings_from_backend
    upcoming = map(convert_program, upcoming)
  File "./mythcal", line 83, in convert_program
    "start": naive_local_time_to_naive_utc_time(prog.starttime),
  File "./mythcal", line 73, in naive_local_time_to_naive_utc_time
    aware_utc_time = aware_local_time.astimezone(pytz.utc)
ValueError: astimezone() cannot be applied to a naive datetime


(my line 73 is your line 70, as I added a couple of comments to my code to go 
along with patching line 69)

Original comment by memory...@gmail.com on 4 Jan 2011 at 3:50

[GoogleCodeExporter]

I can confirm this issue exists with the 0.24 release as well.

Original comment by john.b...@gmail.com on 9 Feb 2011 at 7:07

[GoogleCodeExporter]

Issue 8 has been merged into this issue.

Original comment by richardfearn on 20 Jul 2011 at 8:58

[GoogleCodeExporter]

This issue was closed by revision r23.

Original comment by richardfearn on 24 Jul 2011 at 2:48

• Changed state: Fixed

[GoogleCodeExporter]

MythTV isn't returning timezone information; there are now MythTV-specific 
datetime and tzinfo classes, and the tzinfo class is nested inside datetime. 
This makes it look like the datetime objects have a tzinfo attribute - but it's 
the tzinfo class itself, not an instance of it. The datetime libraries don't 
like this. I've created a ticket in the MythTV Trac:

http://code.mythtv.org/trac/ticket/9937

The workaround is quite simple: create a new, 'ordinary' datetime object using 
the timestamp from the MythTV datetime object. The rest of the code (for 
converting what MythTV provides into a UTC time) works as before.

Original comment by richardfearn on 24 Jul 2011 at 3:36

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

This issue was closed by revision 3eaa73078a50.

Original comment by richardfearn on 5 Jun 2012 at 2:03