As far as I understood there are 2 different xmltv time schemes: 1) '200209080000 +0100' or in your case with seconds '20070215201500 +0100' 2) '20020702100000 CDT'
The timestr2secs_utc() function in xmltv.py supports both. I only changed the second timestring handling. I didn't change the 1 timestring handling. So that part should still work. So in your case it should also still work. > But next is that the timezone value is '+0100' which does not match %Z > (it would match %z but that is not implemented in Python). So your > code will fail, so will all your other guesses. The code wouldn't fail because the +0100 string is handled in the if tz[0] == '+' or tz[0] == '-': statement and timezone strings like CDT or CEST in the 'else 'of that statement. > To fix this once and > for all we need to collect the following information from many > grabber: > > 1. Is there a timezone setting? > > 2. If yes, is it like +0100 or something like EST, CEST? > > 3. Is it correct? In my case above it is. I live in +0100 in winter > (the example is not summer time) and it starts at 20:00. As far as I can see point 1 to 3 are already implemented. > > 4. Would it still be correct if we don't parse the timezone? In my > case yes, because my local time is +0100. As example, > 20070215190000 +0200 would not be ok. I would say here to use the local timezone of the system. That is probably the best choice. Jose ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Freevo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freevo-devel
