http://bugs.gpodder.org/show_bug.cgi?id=143
--- Comment #4 from Nick <[EMAIL PROTECTED]> 2008-07-13 00:19:04 --- Created an attachment (id=122) --> (http://bugs.gpodder.org/attachment.cgi?id=122) gPodder-r766-format_date-fix.patch The attached patch should fix the bug you reported. Although while playing with the code I found another subtle bug that's somewhat related. Feedparser returns dates in a 9-digit tuple but it uses UTC, not the local timezone. Since we use time.mktime() on the feedparser pubdate this presents a problem in the following situation (keep in mind that my timezone is -0400): Episode pubdate: 'Thu, 10 Jul 2008 17:44:04 -0700' >>> feedparser._parse_date('Thu, 10 Jul 2008 17:44:04 -0700') (2008, 7, 11, 0, 44, 4, 4, 193, 0) >>> time.localtime(time.mktime((2008, 7, 11, 0, 44, 4, 4, 193, 0))) (2008, 7, 11, 1, 44, 4, 4, 193, 1) Notice that the result is the following day even though it's supposed to be only + 3 hours. By storing a UTC timestamp in the db we avoid these problems. This can easily be done with rfc822.mktime_tz(): >>> t = feedparser._parse_date('Thu, 10 Jul 2008 17:44:04 -0700') >>> localtime(rfc822.mktime_tz( t + (0,) )) (2008, 7, 10, 20, 44, 4, 3, 192, 1) Now the timestamp is the proper day and it's -4 hours from UTC :) -- Configure bugmail: http://bugs.gpodder.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes. _______________________________________________ gPodder-Bugs mailing list [email protected] https://lists.berlios.de/mailman/listinfo/gpodder-bugs
