Regarding the different timezone formats, I only use the +1000 format (I wrote my own xlmtv grabber). And I guess that's why timestr2secs_utc() works for me. It definitely fixed the scheduling for me.
Without making the change to use timestr2secs_utc I got an hour error when the scheduler writes the freevo_record.lst and another hour error when the recording_daemon loads the file. Does the standard scheduling stuff work for anyone else who uses the +XXXX timezone format in their xmltv files ? Alex -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Erland Lewin Sent: Monday, 31 March 2003 6:58 PM To: [EMAIL PROTECTED] Subject: Re: [Freevo-devel] Problems with timezones and scheduling (possible bug) Alex Brown wrote: >[...] >I was able to fix these problems by replacing the calls to strptime >(which seems broken when working with timezones) with the >'timestr2secs_utc()' method in epg_xmltv.py. > FWIW, I can confirm that strptime doesn't work with time zones - neither the version built into Python, nor the special strptime.strptime function included in freevo. I fixed a time zone bug a while back due to that problem. >timestr2secs_utc() takes xmltv format time string >which is easy to make from the data that was being passed to strptime. > Looking at the timestr2secs_utc function, it uses the broken strptime call, if the time zone is in three-letter format (rather than '+0100' format. So I don't see how replacing a direct call to strptime with a call to timestr2secs_utc would change anything! It would be interesting if you could track down exactly what is happening. My guess is that perhaps the time zone is being ignored in two places - which might cancel each other out. I had this happen when I was mucking about in this code. The fundemental problem is that timezones of the style 'BST' are evil - they are not standardized or well-defined. The 'BST' example can mean either "British Summer Time" or "Brazil Standard Time" if I remember correctly. There are not even any standard OS calls to parse time zones for this reason. See my posting to the xmltv-dev mailing list: http://sourceforge.net/mailarchive/forum.php?thread_id=1784917&forum_id=7180 The only solution that I can see is to never use three-letter time zone names, but always either implicitly know that the time is local or in UTC, or use the '+0100' syntax for time zone specification. >If this needs fixing, then the freevo_record.lst format might need to >be changed to store the timezone (unless we say that the stored times >are UTC). > One reason for storing times in UTC in the files, is for proper functionality through daylight saving time changes, since UTC times are not affected by this, but local time might actually have two different hours with the same times. I would encourage you to ask your xmltv-script provider to not use three-letter time zones names. Happy Hacking, Erland ------------------------------------------------------- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ _______________________________________________ Freevo-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-devel ------------------------------------------------------- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ _______________________________________________ Freevo-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-devel
