Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[VarDumper] Dumping DateTime throws error if getTimezone is false #50644

Merged
merged 1 commit into from Jun 20, 2023

Conversation

bogdanmoza
Copy link
Contributor

Q A
Branch? 5.4
Bug fix? yes
New feature? no
Deprecations? no
Tickets -
License MIT
Doc PR

TL;DR:
In case you have a DateTime object that returns false when calling getTimezone(), an error is thrown in DateCaster.

Description
So I have encountered this case when I have tried to dump a mocked DateTime object. The mock will not have a timezone making the getTimezone() method return false. I know that this is not really a bug, as a DateTime object not having a DateTimeZone should not be happening, but it is possible in case someone extends the DateTime object and overrides the getTimezone() method.
The error thrown is 'The DatetimeInterface object has not been correctly initialized by its constructor'

How to reproduce

class A extends \DateTime {
    public function getTimezone(): \DateTimeZone|false
    {
        return false;
    }
}

Dump the A class will cause an error.

Final notes
Even though this a special case, I still think that you should be able to dump a mocked DateTime.
I hope the description and everything is ok as this is my first pr here.

Cheers!

@carsonbot
Copy link

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.4 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

Copy link
Member

@derrabus derrabus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add a test that covers your change.

src/Symfony/Component/VarDumper/Caster/DateCaster.php Outdated Show resolved Hide resolved
@derrabus
Copy link
Member

Thank you for your PR. I disagree with the motivation of your change for two reasons:

  • I don't want to implement workarounds for broken mocks. Your mock probably does not behave like the DateTime objects your code is usually dealing with. That is a clear sign that you should fix your mock.
  • Mocking DateTime is in most cases a very pointless thing to do. One exception might be testing this very edge case. 🙈

However as per PHP's documentation, false is a possible return value of getTimezone(), so VarDumper should be able to handle it.

I'm fine with the change, once my review has been addressed.

@bogdanmoza
Copy link
Contributor Author

Thanks for the quick reply, you are right about the motivation, what I was thinking is that since PHP enables you to return false, then of course that allows for some special cases like dumping a Mock, and it is possible without a Mock also.

$location = $d->getTimezone()->getLocation();
$fromNow = (new \DateTime())->diff($d);
$location = $d->getTimezone() ? $d->getTimezone()->getLocation() : null;
$fromNow = $d->getTimezone() ? (new \DateTime())->diff($d) : null;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I reverted this change

@nicolas-grekas
Copy link
Member

Thank you @bogdanmoza.

@nicolas-grekas nicolas-grekas merged commit 46cda10 into symfony:5.4 Jun 20, 2023
9 of 11 checks passed
This was referenced Jun 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants