ZF-7908: getDateModified() returns incorrect date if RSS feed has near-standard date formatting

Issue Type: Bug Created: 2009-09-21T07:05:46.000+0000 Last Updated: 2010-01-04T06:41:49.000+0000 Status: Resolved Fix version(s): - 1.9.3 (22/Sep/09)

Reporter: Christophe Deliens (cdeliens) Assignee: Pádraic Brady (padraic) Tags: - Zend_Feed_Reader

Related issues: - ZF-7914

Attachments: - Rss.patch


I have the following date in a RSS feed: Sun, 11 Jan 2009 09:55:59 GMT

The getDateModified function in Zend_Feed_Reader_Entry_Rss returns a Zend_Date object corresponding to: Sun, 01 Nov 2009 09:55:59 +0000

Expected result: Sun, 11 Jan 2009 09:55:59 +0000

This is a month/day inversion (m-d-Y is US standard, d-m-Y is EU standard).

As it looks like php's builtin strtotime function understands/translates the date string properly, I propose to first try a strtotime conversion before attempting a Zend_Date resolution using RFC standards.

(updated 2009-09-21 16:46 UTC) Proposed working patch for Zend/Feed/Reader/Entry/Rss.php (rev 16966, Zend Framework v1.9.2):

<pre class="highlight">
>               $dateModifiedParsed = strtotime($dateModified);
>               if ($dateModifiedParsed) {
>                   $date = new Zend_Date($dateModifiedParsed);
>               } else {
>         }


Posted by Christophe Deliens (cdeliens) on 2009-09-21T07:06:28.000+0000

Rss.php patch file

Posted by Pádraic Brady (padraic) on 2009-09-21T08:17:14.000+0000

Fixed (for given example) in r18340.

Thanks for the report! Give the fix a whirl (in trunk and release-1.9 branch) to see if it checks out for any other dates in the same feed.

Posted by Christophe Deliens (cdeliens) on 2009-09-21T09:41:52.000+0000

Patch #1 was incorrect... please use this one instead on original file.

Posted by Pádraic Brady (padraic) on 2009-09-21T10:21:29.000+0000

Issue is resolved - the example in the description can be parsed using the Zend_Date::RSS option as a second to last resort (really should be RFC 822 or 2822 per the RSS Advisory Standard). So while the patch is not applied, the alternative change does work for the given example.

Posted by Christophe Deliens (cdeliens) on 2009-09-21T23:34:03.000+0000

I don't agree Pádraic.

Look closer at the first patch: if "strtotime" can't parse, PHP will return false. So the variable $dateModified will be FALSE and that value will tried to be parsed by the next "->set" instructions, which will end in the latest Exception catch and FAIL.

Trust me, I had the problem.

Posted by Pádraic Brady (padraic) on 2009-09-22T04:25:49.000+0000

I'm not sure you're following the logic from the start in how I resolved this. The original issue description includes one example of the problematic parsing. I added a unit test to check the bug exists, using the unit test I added the new parsing set() call, the unit test then passed. Therefore I resolved the issue as fixed. I can't add yet another parsing attempt without a reason to do so, and a unit test to support its application against a date no other step could parse. Is there another date type which requires strtotime()?

Have you found an issue?

See the Overview section for more details.


© 2006-2018 by Zend, a Rogue Wave Company. Made with by awesome contributors.

This website is built using zend-expressive and it runs on PHP 7.