Skip to content

[Serializer] Allows the DateTimeNormalizer to use the FORMAT_KEY used in construct… #33813

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
wants to merge 1 commit into from

Conversation

CheapHasz
Copy link

Allows the DateTimeNormalizer to use the FORMAT_KEY used in construct or in the denormalize method

Q A
Branch? 4.3
Bug fix? yes
New feature? no
Deprecations? no
Tickets Fix #29030
License MIT

The default format, passed to the constructor, wasn't considered when denormalizing a DateTime.

I needed to store it in a different property, as the format from defaultContext, \DateTime::RFC3339, was causing a BC Break and making it a hassle to denormalize simpler formats, and was failing a bunch of other tests.

Copy link

@Bloodysunset Bloodysunset left a comment

Choose a reason for hiding this comment

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

Seems good to me 👍

@nicolas-grekas nicolas-grekas added this to the 4.3 milestone Oct 2, 2019
@nicolas-grekas nicolas-grekas modified the milestones: 4.3, 4.4 Feb 1, 2020
@fabpot
Copy link
Member

fabpot commented Aug 19, 2020

Wouldn't it be better to "fix" the bug the proper way and when we cannot parse the date, fall back to the current behavior? That should be BC, right?

@fabpot
Copy link
Member

fabpot commented Sep 19, 2020

Closing as there is no more feedback.

@fabpot fabpot closed this Sep 19, 2020
nicolas-grekas added a commit that referenced this pull request Jul 28, 2022
…::denormalize (hultberg)

This PR was merged into the 4.4 branch.

Discussion
----------

[Serializer] Respect default context in DateTimeNormalizer::denormalize

| Q             | A
| ------------- | ---
| Branch?       | 4.4 <!-- see below -->
| Bug fix?      | yes
| New feature?  |no <!-- please update src/**/CHANGELOG.md files -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tickets       | Fix #29030 <!-- prefix each issue number with "Fix #", no need to create an issue if none exist, explain below instead -->
| License       | MIT
| Doc PR        | <!-- required for new features -->
<!--
Replace this notice by a short README for your feature/bugfix. This will help people
understand your PR and can be used as a start for the documentation.

Additionally (see https://symfony.com/releases):
 - Always add tests and ensure they pass.
 - Never break backward compatibility (see https://symfony.com/bc).
 - Bug fixes must be submitted against the lowest maintained branch where they apply
   (lowest branches are regularly merged to upper ones so they get the fixes too.)
 - Features and deprecations must be submitted against branch 5.x.
 - Changelog entry should follow https://symfony.com/doc/current/contributing/code/conventions.html#writing-a-changelog-entry
-->

Hey there. 👋

I'm bringing my first code patch to symfony today and it's for fixing a bug I encountered today while working with DateTimeNormalizer. In my project I have set a default date format in the service container and I noticed that the denormalized date did not follow my set date format (I enforce time but the serialized date did not contain the time stamp which should have failed when using DateTime::createFromDate). After some debugging I discovered the issue described in issue #29030

`DateTimeNormalizer::normalize` respects the date time format in context or default context while `DateTimeNormalizer::denormalize` only respects the former. This patch adds logic to denormalize too attempt create a DateTime object from the default context format (by default set to `\DateTime::RFC3339`) with createFromFormat and then if that fails continue on with the current behaviour. In my opinion this patch does not break the symfony BC promise as it simply adds another way to denormalize the date time.

**One issue:** There are no error handling when creating the date time from default context as the logic just continues on which might give the impression to the developer that the denormalization with the specific format worked correctly. I was not able to find a way to handle any error and keeping BC.
**Future tough:** At some point the `new DateTime` call in denormalize should be deprecated since creating a date time with createFromFormat is considered "safer" in my eyes as it's very explicit while the call to `new DateTime` is implicit about the date format and must perform parsing and guessing of the intended format (explained over at https://www.php.net/manual/en/datetime.formats.php). Another thing about `new DateTime` is the terriable error handling as you must catch a `\Exception` which means you catch "what ever" exception that can exist, even `\ErrorException` since `\ErrorException extends \Exception`.

Fixes #29030
Alternative PR (closed) #33813

Commits
-------

763ea05 [Serializer] Respect default context in DateTimeNormalizer::denormalize
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.

5 participants