-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[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
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Bloodysunset
approved these changes
Oct 2, 2019
There was a problem hiding this 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 👍
…or in the denormalize method
3e401ce
to
bea63f5
Compare
fabpot
approved these changes
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? |
Closing as there is no more feedback. |
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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Allows the DateTimeNormalizer to use the FORMAT_KEY used in construct or in the denormalize method
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.