8.2.9 DateTime:createFromFormat stopped parsing datetime with containing extra space.

[mn7z]

Description

Starting of 8.2.9 version \DateTime:createFromFormat() starts to fail to parse date format, due extra space.

The date string Wed Aug 2 08:37:50 2023 - with extra space between Aug and 2. If extra space is removed
then it works as usual.

PHP versions <8.2.9 correctly parses the format, I've tested with 8.2.7 version in addition to 8.2.8.

The following code:

<?php

$dateTime = \DateTime::createFromFormat("D M d H:i:s Y", "Wed Aug  2 08:37:50 2023");

var_dump($dateTime);

Resulted in this output:

bool(false)

But I expected this output instead:

object(DateTime)#1 (3) {
  ["date"]=>
  string(26) "2023-08-02 08:37:50.000000"
  ["timezone_type"]=>
  int(3)
  ["timezone"]=>
  string(3) "UTC"
}

PHP Version

PHP 8.2.9

Operating System

No response

[damianwadley]

(Note: 8.2.9 GA is planned for tomorrow and has already been tagged.)

@derickr Is it intentional that timelib_eat_spaces now only eats a single character? Because before it would eat as many as it could.
derickr/timelib@b00612f

[levu42]

This currently breaks Laravel's artisan serve command. PHP 8.2.9 has already been shipped on at least arch linux since yesterday https://archlinux.org/packages/extra/x86_64/php/.

Is there any chance for an 8.2.10 to be shipped quickly that fixes this regression?

[nielsdos]

I'm not Derick, but I'm pretty confident that it is unintentional that it now stops at consuming a single space.
The commit changed how it worked to support non-narrow breaking spaces (#11600).
I think I know how to fix it, so maybe I can fix it quickly and we can prevent the regression in the actual release.

[damianwadley]

Is there any chance for an 8.2.10 to be shipped quickly that fixes this regression?

➡️ @saundefined and @adoy

[derickr]

On 2 August 2023 21:15:50 BST, Damian Wadley ***@***.***> wrote: > Is there any chance for an 8.2.10 to be shipped quickly that fixes this regression? ➡️ @saundefined and @adoy

I didn't see this until now, although I was online all day. But these fixes need to be done in derickr/timelib. You'll have to convince the RMs for an early release. It's also surprising there were no tests for this.

[Gemorroj]

@derickr

But these fixes need to be done in derickr/timelib.

derickr/timelib#148

[derickr]

On 2 August 2023 22:24:25 BST, hidden_nickname ***@***.***> wrote: @derickr > But these fixes need to be done in derickr/timelib. derickr/timelib#148

That's good. For some reason that also didn't produce an email notification :-/ — I'll dive into this. In the meanwhile, I don't mind a quick fix here.

[derickr]

I'm in the progress of addressing this regression. But to be precise, this is not a bug. The documentation for createFromFormat lists for the ' ' format:

Whitespace and Separators
(space) | One space or one tab | Example:

I will make sure to update the docs here as well, as that also needs the new NBSP and NNBSP added for PHP 8.2.x.

[damianwadley]

But to be precise, this is not a bug.

If the exact number of whitespace is required then that makes it much, much harder to parse formats where day numbers are two space-padded characters: Aug••2 could be parsed with F••d but not F•d, while Aug•12 could be parsed with F•d but not F••d.

...unless spaces are optional, which seems to be the case now? https://3v4l.org/IcBMe#v8.2.9
Then someone can throw in a whole bunch of spaces when the exact number is ever in question; the pattern is ugly but at least it works.

That aside, is there an actual problem with having a space represent one or more whitespace characters, as the behavior has been for the last 14 years?

[derickr]

No, there is no problem with that at all, that's why we're keeping the behaviour, even though it wasn't originally intended. I've merged the fix now, and will now be updating documentation.

[thg2k]

This is very interesting, I never realized space actually matches one or more spaces. In theory, the correct fix would be to have one space match exactly one space (or tab) and have "j" match any of these: 1 01 11 •1. But there is no reason to cause useless BC breaks.

One could argue that this would be the correct behavior so you could match something like 2023-08-•2 with Y-m-j, but that's quite useless.

[GrahamCampbell]

Is it too late to get this into 8.2.9? I noticed the docs were updated referencing a change in 8.2.9, but that change is maybe only in 8.2.10?

[saundefined]

Is it too late to get this into 8.2.9?

PHP 8.2.9 tarballs rebuilt including that fix.

[levu42]

I think by the way, the real source of the problem is somewhere different: this code (parsing the datetime) is run for re-formatting the output of php -S, which prints - for whatever reason - the date as Thu Aug 3 13:24:43 2023 with that double space.

Then Laravel tries parsing that with the format string D M d H:i:s Y .

So I guess either the php -S output is wrong, or, if it's intended, there might be a different format string for Laravel to use that fits the one used by php -S when outputting the date.

Either way, it's great that the old behavior is restored to avoid unnecessary BC breaks. But out of curiosity, does anyone have some insight whether my thoughts go into the right direction?

[achmadya-dev]

sudo downgrade php this will downgrade your php version and select your last version before update