php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #64040 DateTime::createFromFormat() incorrectly parses illogical dates
Submitted: 2013-01-21 20:21 UTC Modified: 2017-03-30 07:31 UTC
Votes:4
Avg. Score:4.8 ± 0.4
Reproduced:3 of 3 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: tagadvance at gmail dot com Assigned:
Status: Not a bug Package: Date/time related
PHP Version: Irrelevant OS: Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: tagadvance at gmail dot com
New email:
PHP Version: OS:

 

 [2013-01-21 20:21 UTC] tagadvance at gmail dot com 
Description:
------------
---
From manual page: http://www.php.net/datetime.createfromformat
---
The DateTime::createFromFormat() method incorrectly parses an illogical date. I 
have tested this on version 5.3.3 (CentOS) and 5.4.6 (Ubuntu).

Test script:
---------------
<?php

// November 16 falls on a Friday, NOT a Wednesday
$date = 'Wednesday 16 November 2012';
$format = 'l d M Y';

try {
	$dateTime = DateTime::createFromFormat($format, $date);
	$formattedDateTime = $dateTime->format($format);
	echo $formattedDateTime . PHP_EOL; // prints "Wednesday 21 Nov 2012"
} catch (Exception $e) {
	// no exception is thrown =(
	echo $e->getMessage();
}

?>

Expected result:
----------------
I expect the createFromFormat method to throw an error if the date is illogical. 
At the very least a warning should be added to the log.

Actual result:
--------------
The createFromFormat parses the illogical date. The day seems to take precedence 
over the date. I am just guessing here, but it then seems to round up by one week 
so that the date makes sense.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2014-04-25 07:16 UTC] metamarkers at gmail dot com 
"Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?"

There is no amount of code that can be written to error-correct the programmer.
 [2014-06-25 13:19 UTC] nicodoggie at gmail dot com 
Taking the same code as OP, another example of parsing illogical dates:

<?php

// November 16 falls on a Friday, NOT a Wednesday
$date = '2014-22-01';
$format = 'Y-m-d';

try {
	$dateTime = DateTime::createFromFormat($format, $date);
	$formattedDateTime = $dateTime->format($format);
	echo $formattedDateTime . PHP_EOL; // prints "2014-10-01"
} catch (Exception $e) {
	// no exception is thrown =(
	echo $e->getMessage();
}

?>

It would be better to throw out a warning, or at least give us a $useStrict = false parameter to play with so we don't break anyone's weird implementation.

Tested on ArchLinux PHP 5.5.13
 [2017-03-29 19:44 UTC] php-bugs at allenjb dot me dot uk 
DateTime does issue a warning through its own internal warning system (DateTime->getLastErrors()) and always has done as far as I can see: https://3v4l.org/uGDe7
 [2017-03-30 07:31 UTC] requinix@php.net
-Status: Open +Status: Not a bug
 [2017-03-30 07:31 UTC] requinix@php.net 
DateTime tries its best. Returning something rational (Fri 16 Nov 2012 + Wednesday = Wed 21 Nov 2012) with a warning is better than nothing.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Apr 25 01:01:30 2024 UTC