Bug #55575 [Nab]: strtotime() returns erroneous result on nonsense DATE_RSS format date strings

From: Date: Thu, 17 Jul 2014 19:16:25 +0000
Subject: Bug #55575 [Nab]: strtotime() returns erroneous result on nonsense DATE_RSS format date strings
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-186706@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=55575&edit=1 ID: 55575 User updated by: vlayne dot tech+bugsphp at gmail dot com Reported by: vlayne dot tech+bugsphp at gmail dot com Summary: strtotime() returns erroneous result on nonsense DATE_RSS format date strings Status: Not a bug Type: Bug Package: Date/time related Operating System: Linux & Darwin PHP Version: 5.3.8 Block user comment: N Private report: N New Comment: > How are we supposed to properly handle nonsense? By throwing an error. Returning different nonsense is failing silently. Previous Comments: ------------------------------------------------------------------------ [2014-07-17 14:15:27] salathe@php.net Date strings sent to strtotime() can consist of absolute and relative parts. For "Tue, 9 May 2010 04:24:36 GMT": - absolute parts are processed first "9 May 2010 04:24:36 GMT" - then, the relative part "Tue" is processed This last step, as detailed on the Relative Formats [1] manual page, shifts the date to the 11th, which is the next Tuesday. This behaviour makes much more sense than ignoring parts of the subject date string, or disallowing relative date parts and instead throwing an error. [1] http://php.net/datetime.formats.relative ------------------------------------------------------------------------ [2014-07-17 12:40:24] datibbaw@php.net How are we supposed to properly handle nonsense? How are you sure that what you have proposed is the correct way of dealing with this? Have you seen other implementations that do this? ------------------------------------------------------------------------ [2011-09-03 04:04:09] vlayne dot tech+bugsphp at gmail dot com Description: ------------ (Note: I was only able to test on 5.2.16, 5.3.0, and 5.3.4. Since there is no evidence of it being fixed in the changelog of 5.3.8, I assume it's still there.) The ninth of May, 2010, was a Sunday. However, if you assert to strtotime() that it was a Monday, it will return the Unix timestamp for Monday, May 10th. Likewise if you assert the ninth was a Tuesday, it will return the timestamp for the 11th; a Wednesday the 12th, and so on right up to returning a Unix timestamp for Saturday, 15 May 2010 if you provide it with "Saturday, 9 May 2010". Presumably, the correct behavior is one of (1) to throw an error given a self- contradictory date, (2) to return nothing at all, or (3) to ignore the day-of-the- week element and return the Unix timestamp for the date specified (e.g. 9 May 2010). Returning the timestamp for another date altogether is wrong. Test script: --------------- $datestring="9 May 2010 04:24:36 GMT"; print "\"\": ".strtotime($datestring)." ".date($dateformat, strtotime($datestri\ ng)) ."\n"; $datestring="Sun, 9 May 2010 04:24:36 GMT"; print "Sun: ".strtotime($datestring)." ".date($dateformat, strtotime($datestrin\ g)) ."\n"; $datestring="Mon, 9 May 2010 04:24:36 GMT"; print "Mon: ".strtotime($datestring)." ".date($dateformat, strtotime($datestrin\ g)) ."\n"; $datestring="Tue, 9 May 2010 04:24:36 GMT"; print "Tue: ".strtotime($datestring)." ".date($dateformat, strtotime($datestrin\ g)) ."\n"; Expected result: ---------------- "": 1273379076 Sun, 09 May 2010 00:24:36 -0400 Sun: 1273379076 Sun, 09 May 2010 00:24:36 -0400 Mon: 1273379076 Sun, 09 May 2010 00:24:36 -0400 Tue: 1273379076 Sun, 09 May 2010 00:24:36 -0400 (Alternatively: "": 1273379076 Sun, 09 May 2010 00:24:36 -0400 Sun: 1273379076 Sun, 09 May 2010 00:24:36 -0400 Mon: Tue: ) Actual result: -------------- "": 1273379076 Sun, 09 May 2010 00:24:36 -0400 Sun: 1273379076 Sun, 09 May 2010 00:24:36 -0400 Mon: 1273465476 Mon, 10 May 2010 00:24:36 -0400 Tue: 1273551876 Tue, 11 May 2010 00:24:36 -0400 ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=55575&edit=1

« previous php.bugs (#186706) next »