libo26 / feedparser

Automatically exported from code.google.com/p/feedparser
Other
0 stars 0 forks source link

ISO-8601 date/time parser creates invalid time due to timezone #299

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
_parse_date_iso8601, when given an ISO8601 format time string with timezone 
offset, converts the time to UTC before calling mktime.  However, mktime 
expects a local time, not a UTC time.

See attached "baddate.py" script.  This generates ISO8601 time strings for both 
local time and for UTC time, passes them through _parse_date_iso8601, and 
prints the results.  For UTC time, the parsed date is the same as the original 
date.  For local time, it's not correct.

-- using UTC time --

Original time = Sat Jul 23 16:52:25 2011 (2011, 7, 23, 16, 52, 25, 5, 204, 0)
   ISO format = 2011-07-23T16:52:25Z
  Parsed time = Sat Jul 23 16:52:25 2011 (2011, 7, 23, 16, 52, 25, 5, 204, 1)

-- using local time --

Original time = Sat Jul 23 09:52:25 2011 (2011, 7, 23, 9, 52, 25, 5, 204, 1)
   ISO format = 2011-07-23T09:52:25-07:00
  Parsed time = Sat Jul 23 16:52:25 2011 (2011, 7, 23, 16, 52, 25, 5, 204, 1)

What version of the product are you using? On what operating system?

Using feedparser 5.0.1 on python 2.5.1

Please provide any additional information below.

suggessted patch:

diff -u feedparser-5.0.1/feedparser/feedparser.py feedparser.py
--- feedparser-5.0.1/feedparser/feedparser.py   2011-02-20 14:41:24.000000000 
-0800
+++ feedparser.py       2011-07-23 09:57:22.252753000 -0700
@@ -3074,6 +3074,10 @@
             tm[4] -= int(params.get('tzmin', 0))
         else:
             return None
+        # adjust from UTC to local time for time.mktime()
+        mytz = (time.daylight and time.altzone or time.timezone)
+        tm[3] -= (mytz/3600)
+        tm[4] -= ((mytz%3600)/60)
     # Python's time.mktime() is a wrapper around the ANSI C mktime(3c)
     # which is guaranteed to normalize d/m/y/h/m/s.
     # Many implementations have bugs, but we'll pretend they don't.

Original issue reported on code.google.com by darkfoxp...@gmail.com on 23 Jul 2011 at 4:59

Attachments:

GoogleCodeExporter commented 9 years ago
I don't understand what the problem is. The sample ISO-formatted times you gave 
above are equivalent and the 9-tuple returned for both is equivalent and in 
UTC. Can you provide additional information why the behavior is incorrect?

Original comment by kurtmckee on 8 Sep 2011 at 5:09

GoogleCodeExporter commented 9 years ago
To be truthful, I no longer remember - I switched from using feedparser to 
another library that was more specific to my application shortly after posting 
this.

You can close this as not-an-issue, or whatever the appropriate response is.  
Sorry to waste your time.

Original comment by darkfoxp...@gmail.com on 8 Sep 2011 at 2:03

GoogleCodeExporter commented 9 years ago
You didn't waste my time at all! Investigating feedparser issues makes the 
software better for everybody. :)

Original comment by kurtmckee on 8 Sep 2011 at 3:09