8000 [Serializer] Remove datetime serializer by Marion-Valls · Pull Request #48982 · symfony/symfony · GitHub
[go: up one dir, main page]

Skip to content

[Serializer] Remove datetime serializer #48982

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

Closed

Conversation

Marion-Valls
Copy link
Q A
Branch? 6.3
Bug fix? no
New feature? yes
Deprecations? no
Tickets #47580
License MIT
Doc PR symfony/symfony-docs

Remove DateTime from all core bundles.

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

@Kocal
Copy link
Member
Kocal commented Jan 14, 2023

What if people uses DateTime in their application?

@@ -148,7 +148,8 @@
"symfony/security-acl": "~2.8|~3.0",
"twig/cssinliner-extra": "^2.12|^3",
"twig/inky-extra": "^2.12|^3",
"twig/markdown-extra": "^2.12|^3"
"twig/markdown-extra": "^2.12|^3",
"vimeo/psalm": "^5.0@dev"
Copy link

Choose a reason for hiding this comment

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

you shouldn't change composer.json, not the scope of this PR. BTW, what was your intention by adding psalm?

self::TIMEZONE_KEY => null,
];

private const SUPPORTED_TYPES = [
\DateTimeInterface::class => true,
\DateTimeImmutable::class => true,
\DateTime::class => true,
Copy link

Choose a reason for hiding this comment

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

Are you sure to drop support of normalization of \DateTime?

Copy link
Member

Choose a reason for hiding this comment

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

This part is a no-go. We must still support normalizing DateTime objects. Otherwise, we force dropping usages of DateTime in all projects instead (and this is a BC break)

@@ -195,7 +190,6 @@ public function testDenormalizeUsingFormatPassedInContext()
{
$this->assertEquals(new \DateTimeImmutable('2016/01/01'), $this->normalizer->denormalize('2016.01.01', \DateTimeInterface::class, null, [DateTimeNormalizer::FORMAT_KEY => 'Y.m.d|']));
$this->assertEquals(new \DateTimeImmutable('2016/01/01'), $this->normalizer->denormalize('2016.01.01', \DateTimeImmutable::class, null, [DateTimeNormalizer::FORMAT_KEY => 'Y.m.d|']));
$this->assertEquals(new \DateTime('2016/01/01'), $this->normalizer->denormalize('2016.01.01', \DateTime::class, null, [DateTimeNormalizer::FORMAT_KEY => 'Y.m.d|']));
Copy link

Choose a reason for hiding this comment

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

As normalization of \DateTime should be still supported, you should restore this test.

Comment on lines -179 to -180
$this->assertEquals(new \DateTime('2016/01/01', new \DateTimeZone('UTC')), $this->normalizer->denormalize('2016-01-01T00:00:00+00:00', \DateTime::class));
$this->assertEquals(new \DateTime('2016/01/01', new \DateTimeZone('UTC')), $this->normalizer->denormalize(' 2016-01-01T00:00:00+00:00 ', \DateTime::class));
Copy link

Choose a reason for hiding this comment

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

As normalization of \DateTime should be still supported, you should restore this test.

@@ -88,29 +87,29 @@ public function denormalize(mixed $data, string $type, string $format = null, ar
}

if (null !== $dateTimeFormat) {
$object = \DateTime::class === $type ? \DateTime::createFromFormat($dateTimeFormat, $data, $timezone) : \DateTimeImmutable::createFromFormat($dateTimeFormat, $data, $timezone);
Copy link

Choose a reason for hiding this comment

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

As $type is an argument, be careful to still support this way for users to decide of final normalization.

self::TIMEZONE_KEY => null,
];

private const SUPPORTED_TYPES = [
\DateTimeInterface::class => true,
\DateTimeImmutable::class => true,
\DateTime::class => true,
Copy link
Member

Choose a reason for hiding this comment

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

This part is a no-go. We must still support normalizing DateTime objects. Otherwise, we force dropping usages of DateTime in all projects instead (and this is a BC break)

@Marion-Valls Marion-Valls changed the title [Serialiser] Remove datetime serializer [Serializer] Remove datetime serializer Jan 16, 2023
@stof
Copy link
Member
stof commented May 4, 2023

@Marion-Valls what is the state of this PR ? Will you work on fixing the feedback ?

@nicolas-grekas nicolas-grekas modified the milestones: 6.3, 6.4 May 23, 2023
8000 @nicolas-grekas nicolas-grekas modified the milestones: 6.4, 7.1 Nov 15, 2023
@xabbuh xabbuh modified the milestones: 7.1, 7.2 May 15, 2024
@fabpot fabpot modified the milestones: 7.2, 7.3 Nov 20, 2024
@chalasr
Copy link
Member
chalasr commented Mar 29, 2025

Closing as there is no more activity here. Thanks for trying

@chalasr chalasr closed this Mar 29, 2025
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.

9 participants
0