Bug #76731 [Opn]: Date time format parsing is wrong for format Ynd

Edit report at https://bugs.php.net/bug.php?id=76731&edit=1 ID: 76731 Updated by: derick@php.net 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: Your first sample fails because you didn't specify the - in your format: derick@singlemalt:~ $ php <?php $date = DateTime::createFromFormat("Y-m-d", "2000-10-1"); var_dump($date); Standard input code:3: class DateTime#1 (3) { public $date => string(26) "2000-10-01 07:55:25.000000" public $timezone_type => int(3) public $timezone => string(3) "UTC" } Works just fine here. The format characters in createFromFormat take *up* to the amount of characters acceptable for the format. So indeed, the "Y" parses 4 characters ("2000"), the "m" parses 2 characters ("10"), and the "d" up to 2 characters, but as there is only one, it parses only "1". Previous Comments: ------------------------------------------------------------------------ [2018-08-13 00:58:02] requinix@php.net > Both the month and day specifier are padded in 'Ymd' Optionally padded. 2000101 gets parsed as Y=2000 m=10 d=1 so the zero isn't being reused. PHP takes whatever digits are available when deciding whether to use one or two digits. If there are two digits available then they both will be used. That's why "200012" does not work with Ymd: Y=2000, m=12 because there are two digits available, and since there's nothing left for d to match it fails. Even though it could have matched with m=1 d=2. ------------------------------------------------------------------------ [2018-08-12 23:24:05] a at b dot c dot de 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" ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=76731 -- Edit this bug report at https://bugs.php.net/bug.php?id=76731&edit=1