[Form] deprecate using the date and time types with date objects with not-matching timezones #46426
Conversation
97a0564 to
95e119b
Compare
|
Status: Needs Review |
|
EDIT: no model transformation to hook into for such cases |
|
Should we create a dedicated listener that can be used in other |
bc464f2 to
9baadc8
Compare
9baadc8 to
bf7222a
Compare
I don't think we need to extract this into a dedicated listener, but you are right that we should trigger the deprecation in these types as well. I have updated the code accordingly. Status: Needs Review |
4a73df7 to
3317b72
Compare
|
Is this one ready for another round of reviews? |
949df05 to
ec03721
Compare
|
Yes, the PR is ready to be reviewed again. |
| } | ||
|
|
||
| if ($date->getTimezone()->getName() !== $options['model_timezone']) { | ||
| trigger_deprecation('symfony/form', '6.3', sprintf('Using a "%s" instance with a timezone ("%s") not matching the configured model timezone "%s" is deprecated.', $date::class, $date->getTimezone()->getName(), $options['model_timezone'])); |
There was a problem hiding this comment.
I think we're missing some inline comment to know what to do with this in 7.0.
Are we going to throw something? If yes, can we add the anticipated line as a comment already?
Same for tests: how should they be changed in 7.0? Let's add some commented expectException?
|
friendly ping @xabbuh :) |
7b782eb to
1c78bae
Compare
1c78bae to
b78bfbc
Compare
|
Thank you @xabbuh. |
|
Hi guys, This change is breaking our app because Having to normalize the timezone of a hundred of Can you elaborate on the issues that prompted this PR? In short, is throwing an exception to the face of the user the right approach? |
|
@fmarchalemisys Please open a new issue. Comments on merged PRs are likely to get lost. |
Uh oh!
There was an error while loading. Please reload this page.