php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #64414 DateTime::createFromFormat() fails randomly when using microtime(true) as input
Submitted: 2013-03-12 18:41 UTC Modified: 2013-03-13 20:51 UTC
From: rewilliams at newtekemail dot com Assigned:
Status: Not a bug Package: Date/time related
PHP Version: 5.4.12 OS: Red Hat 6.2; OS X 10.7.5
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
28 - 19 = ?
Subscribe to this entry?

 
 [2013-03-12 18:41 UTC] rewilliams at newtekemail dot com
Description:
------------
I have available to me the following PHP versions:

* PHP 5.4.11 running on OS X 10.7.5
* PHP 5.3.15 (Suhosin) running on OS X 10.7.5 (Apple's install)
* PHP 5.3.9 running on Red Hat Enterprise Linux 6.2

I'm able to easily reproduce this on all versions.

Essentially, what's happening is that randomly,
DateTime::createFromFormat() will return false, with the error "Data
missing" as reported by DateTime::getLastErrors(). For testing purposes,
I'm calling it in a loop until I see failure or until one million
iterations have run. On 5.4.11, probably 60% of test runs fail, while it
fails more often on older versions. When it does fail, it seems to be
random how many iterations it gets through - sometimes, just a few thousand
iterations, other times, mid-way or all the way through.

Notably, in our production environment (running 5.4.11), which is where we
discovered this, we only make the method call one or two times over the
course of an average request.

The parameters I'm passing in my test code are the only ones with which
I've seen this failure. With, say, 'Y-m-d H:i:s' as a format string, it
works every time for me. Related, it doesn't appear to be the microtime()
call itself failing, as I've put that in a loop by itself and not observed
a failure.

Below is an example of the error that's produced when it fails. Note that
in this case, it failed on iteration number 913,371.


[...]
800000
850000
900000
It failed!
i: 913371
bool(false)
array(4) {
  ["warning_count"]=>
  int(0)
  ["warnings"]=>
  array(0) {
  }
  ["error_count"]=>
  int(1)
  ["errors"]=>
  array(1) {
    [10]=>
    string(12) "Data missing"
  }
}

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

ini_set('display_errors', true);
ini_set('error_reporting', E_ALL | E_STRICT);

for ($i = 1; $i < 1e6; $i++) {
	if ($i % 50000 == 0) echo $i . "\n";
	
	$foo = \DateTime::createFromFormat('U.u', \microtime(true));
	if (!($foo instanceof DateTime)) {
		echo "It failed!\ni: $i\n";
		var_dump($foo, DateTime::getLastErrors());
		exit;
	} else {
		$foo->format('Y-m-d\TH:i:s.uP');
	} //if-else
} //for

?>

Expected result:
----------------
The DateTime::createFromFormat() call should work every time when given valid 
parameters.

Actual result:
--------------
The DateTime::createFromFormat() call should works almost every time when given 
valid parameters, but fails randomly. The reported error is "Data missing".

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-03-12 18:45 UTC] rewilliams at newtekemail dot com
Updated test script:


<?php

ini_set('display_errors', true);
ini_set('error_reporting', E_ALL | E_STRICT);

for ($i = 1; $i < 1e6; $i++) {
	if ($i % 50000 == 0) echo $i . "\n";
	
	$foo = \DateTime::createFromFormat('U.u', \microtime(true));
	if (!($foo instanceof DateTime)) {
		echo "It failed!\ni: $i\n";
		var_dump($foo, DateTime::getLastErrors());
		exit;
	} //if
} //for

?>

I removed the else clause; it's unrelated and doesn't need to be there.
 [2013-03-13 20:51 UTC] salathe@php.net
This looks to be a case of Garbage In, Garbage Out [1].  Your apparent "random" 
misbehaviour is caused when the string representation of the float returned from 
microtime(true) does not match the format string provided as the first argument to 
DateTime::createFromFormat(). Printing out the string value of the microtime that 
fails clearly shows this [2].

I would recommend providing an appropriate string value in the 
DateTime::createFromFormat() call, matching "U.u" format. For example, using 
something like sprintf("%.6F", microtime(true)).

Unfortunately, though it would be nice, using the string return value from 
microtime(), when called without the $get_as_float argument set to true, is 
currently not an option [3].


[1] http://en.wikipedia.org/wiki/Garbage_in,_garbage_out
[2] https://gist.github.com/salathe/5155971
[3] https://bugs.php.net/bug.php?id=60089
 [2013-03-13 20:51 UTC] salathe@php.net
-Status: Open +Status: Not a bug
 [2020-01-27 17:37 UTC] nolife at gmail dot com
The response and "not a bug" declaration is shameful for the entire PHP project.
microtime() is a PHP internal routine
createFromFormat() is a PHP internal routine

If this is not a bug, nothing in the world ever has been a bug.

This is causing millions of errors worlwide, every single PHP project that formats the timestamp with milliseconds is having random errors whenever the float value doesn't have precision.

How on earth could this bug stay in PHP code for so many years ?
 [2020-06-02 13:20 UTC] lunakid at gmail dot com
Acknowledging that it's indeed one of the most embarrassing and "evil" surprises of PHP, this is a float -> string conversion problem, not a date formatting bug. A float should've always consistently had a fractional part, even if the value "seems to be" integer (".0"), but it doesn't.

(As with many other "handy features" like magic quotes, registering globals, safe mode etc., short-term practical reasons have historically drove design decisions: PHP was never really aspired to be a "serious" language (at least before v5), so random historical cruft's still causing headache accordingly. As to fixing it (assuming willingness solely for the thought experiment): even though there have been lots of bigger breaking changes in the past to undo previous decisions, this behavior may be more difficult to cleanly deprecate, and silent value changes could even cause more subtle problems than this existing one. I'd personally still bite the bullet and do it anyway, though...)
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 12:01:27 2024 UTC