|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[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".
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Wed May 07 12:01:32 2025 UTC |
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.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=60089Acknowledging 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...)