I tracked it down to the strptime used when processing date/times specified with +0100 style timezone specification. strptime interprets the time as local time, but we would like it to interpret it as UTC, and then do the time zone adaptation ourselves.
Basically what happens is this (in str/tv/epg_xmltv.py, function timestr2secs_utc): The function is called with "200209080000 +0100". It does the strptime call on line 318, which returns a secs value representing the date 2002-09-08 00:00 in *local time*, equivalent to 2002-09-08 01:00 in UTC. This is then adjusted by subtracting one hour to compensate for the time zone, ending up with 2002-09-07 23:00 in local time and 2002-09-08 00:00 in UTC. What we wanted to get was 2002-09-07 23:00 in UTC.
I would think that the code used for time zones specified by name won't work either, because the strptime.strptime call can't handle time zones, as far as I can see (only has code for daylight savings time manipulation). FWIW my local c library time.strptime function can't handle time zones either.
So the problem has been located, but I havn't yet fixed it. I just found the Python calendar.gmtime function (argh! hidden in the calendar module rather than the time module like all other functions dealing with unix time stamps and tm tuples), which I think is the key to fixing it. I'll try to submit a patch this evening.
Happy Hacking,
Erland
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Freevo-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-devel
