Hey!

I see that this is your first PR. That is great! Welcome!

Symfony has a contribution guide which I suggest you to read.

In short:

• Always add tests
• Keep backward compatibility (see https://symfony.com/bc).
• Bug fixes must be submitted against the lowest maintained branch where they apply (see https://symfony.com/releases)
• Features and deprecations must be submitted against the 6.3 branch.

Review the GitHub status checks of your pull request and try to solve the reported issues. If some tests are failing, try to see if they are failing because of this change.

When two Symfony core team members approve this change, it will be merged and you will become an official Symfony contributor!
If this PR is merged in a lower version branch, it will be merged up to all maintained branches within a few days.

I am going to sit back now and wait for the reviews.

Cheers!

Carsonbot

Hey!

Thanks for your PR. You are targeting branch "6.3" but it seems your PR description refers to branch "6.3 (?)".
Could you update the PR description or change target branch? This helps core maintainers a lot.

Cheers!

Carsonbot

I'd rather change the type check to also allow integers when using U instead of casting the value before the type check.

And this needs to have tests covering it to prevent regressions

We might want to account for U.u also.
Please use is_int instead of gettype while updating :)

Thank you for the feedback, @stof and @nicolas-grekas.

Is it the better solution to allow integers and floats for U and U.u?
In the PHP documentation the datetime for createFromFormat is typed as a string:

public static DateTimeImmutable::createFromFormat(string $format, string $datetime, ?[DateTimeZone] $timezone = null): [DateTimeImmutable]|false

With PHP 8.1 following code works just fine (does not return false)

$object = DateTimeImmutable::createFromFormat("U", 1683635480);
$object = DateTimeImmutable::createFromFormat("U.u", 1683635480.111111);

but could this behavior change in the future?

@PercyDwn My guess is that this code would not work fine with strict types.

Is it the better solution to allow integers and floats for U and U.u?

IMO, yes

Okay so I updated the type check to allow integers when dateTimeFormat is "U".
But I ignored "U.u" as writing a test for it was a total mess. I tried allowing floats with "U.u", but i have the feeling that in such a case the data would come as a string, not as a float. I was not able to write a working test where the time (including milliseconds) came as a float and was identical with the resulting denormalized date.

Some of the github tests are failing, but I am not quite sure why.

Fixed by #50251