Edit report at https://bugs.php.net/bug.php?id=76731&edit=1
ID: 76731
Comment by: a at b dot c dot de
Reported by: remy dot fox at simbuka dot com
Summary: Date time format parsing is wrong for format Ynd
Status: Open
Type: Bug
Package: Date/time related
PHP Version: 7.2.8
Block user comment: N
Private report: N
New Comment:
Incidentally, I just noticed that this behaviour is documented on the createFromFormat() page.
"d and j Day of the month, 2 digits with or without leading zeros"
Previous Comments:
------------------------------------------------------------------------
[2018-08-12 23:19:16] a at b dot c dot de
In short: createFromFormat("Ymd", "2000101") should be rejected because it
doesn't have enough digits, right? There should be four for the year, two for the month, and
two for the day.
The test case can be simplified:
$date = DateTime::createFromFormat("d", "1");
var_dump($date);
Of the other "leading zero" format specifiers, "m", "h" and
"H" also parse, but "i" and "s" both fail.
------------------------------------------------------------------------
[2018-08-12 18:06:44] remy dot fox at simbuka dot com
You are right that sometimes there is ambiguity. For example, if we take the string
'2000111' then for the format 'Ynj' it could mean either 11 january or 1
november. This is because both the month and day specifiers are unpadded.
In my example there is no ambiguity though. Both the month and day specifier are padded in
'Ymd' and so the parsing should fail (i.e. return false), because the zero in position 6
is used twice now.
------------------------------------------------------------------------
[2018-08-12 12:49:59] requinix@php.net
I don't think it's reasonable to require PHP to check for ambiguity. It's extra
processing cycles for inputs when in nearly all cases, and I would even say all cases that
aren't due to bad decisions, the input is not ambiguous.
Really, strings like "2000101" are weird - surely anyone serializing a date will use 8
digits, right? I mean, what date is it supposed to represent anyways? You say Oct 1 but it could be
Jan 01 too. As a human, how would you decide?
I'd add a warning to the docs that m/n and d/j (and others) work best when (a) the date parts
are always the full length with zero padding if needed, or (b) there is a clear separation between
the parts. And that otherwise the result is undefined.
------------------------------------------------------------------------
[2018-08-12 12:21:27] remy dot fox at simbuka dot com
Description:
------------
The parsing of the date formats 'Ynd' and 'Ymd' gives a wrong result when
segment in the date are not separated by any characters.
There may be similar issues with other date time format specifier combinations too, but I
haven't tested them.
Test script:
---------------
$date = DateTime::createFromFormat("Ymd", "2000-10-1");
var_dump($date);
$date = DateTime::createFromFormat("Ymd", "2000101");
var_dump($date);
Expected result:
----------------
As we can see, the first $date returns false, which is correct. After all the day value was not
padded with a zero. In the second example, the zero could be interpreted as either part of the month
(i.e. october) or as padding for the day value. The result does not return false but it should.
object(DateTime)#2 (3) {
["date"]=>
string(26) "2000-10-01 05:18:02.000000"
["timezone_type"]=>
int(3)
["timezone"]=>
string(10) "US/Pacific"
}
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=76731&edit=1