Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[Form] deprecate submitting non HTML5 formatted dates #28724

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.

Sign up for GitHub

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

Jump to bottom
Closed
wants to merge 2 commits into from
Closed

[Form] deprecate submitting non HTML5 formatted dates #28724

wants to merge 2 commits into from

Conversation

xabbuh
Copy link
Member

@xabbuh xabbuh commented Oct 4, 2018

Q A
Branch? master
Bug fix? no
New feature? no
BC breaks? no
Deprecations? yes
Tests pass? yes
Fixed tickets #28712 (review)
License MIT
Doc PR

@xabbuh
reverse transform RFC 3339 formatted dates
acf95c3 
Technically, dates formatted according to the HTML specifications do not
contain any timezone information. But since our DateTimeType used to
contain this information in the passed, users had configure their JS
libraries to accept (and create) dates in that format.

To not break BC we should accept these dates and silently ignore the
additional timezone information.
@xabbuh xabbuh added this to the next milestone Oct 4, 2018
@xabbuh xabbuh mentioned this pull request Oct 4, 2018
Merged
@xabbuh
Copy link
Member Author

xabbuh commented Oct 4, 2018

needs to be rebased once #28712 is merged up to master

@nicolas-grekas
Copy link
Member

nicolas-grekas commented Oct 4, 2018 •
edited
Loading

I'm really unsure about this. Having an option means asking devs to make a choice, and making a choice is hard. Here, enabling strict mode (Yay, strict all the things!) means lowering the compatibility with the ecosystem. That's contra the robustness principle.
We have a native date parser that is excellent at parsing real-world date formats, there is no better option for me. We should leverage it.

@xabbuh
Copy link
Member Author

xabbuh commented Oct 4, 2018

To me, this goes along with #28753. If one wants to use HTML 5 features, they should follow the standards IMO. Custom formats are okay, but then you need to be explicit about this (i.e. set html5 to false and configure the format option explicitly). Without being strict, there is too much room for guessing from my point of view which unnecessarily adds uncertainty that makes it hard to fix any date (and time) related bugs.

@xabbuh xabbuh force-pushed the datetime-strict-html5-format branch from f545150 to d0dd6c9 Compare October 4, 2018 14:04
stof
stof reviewed Oct 4, 2018
View reviewed changes
...ny/Component/Form/Extension/Core/DataTransformer/DateTimeToHtml5LocalDateTimeTransformer.php
// to maintain backwards compatibility we do not strictly validate the submitted date
// see https://github.com/symfony/symfony/issues/28699
if (!$this->strict) {
$regex = '/^(\d{4})-(\d{2})-(\d{2})[T ]\d{2}:\d{2}(?::\d{2})?/';
Copy link
Member

Choose a reason for hiding this comment

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

to maintain BC, shouldn't it use the old transformer instead (which did not have that regex either, so you are only partially fixing the BC break)

@stof
Copy link
Member

stof commented Oct 4, 2018

@nicolas-grekas if you have a form type configured as HTML5_FORMAT, supporting other formats looks weird.

The option is here to opt-in for the new behavior at the time you want (needed in case your JS currently generates a different format for instance)

@stof
Copy link
Member

stof commented Oct 4, 2018

We may also want to harden DateTimeToRfc3339Transformer to actually support only RFC 3339 (using DateTime::createFromFormat)

@xabbuh xabbuh force-pushed the datetime-strict-html5-format branch from d0dd6c9 to 3132819 Compare October 4, 2018 14:23
@nicolas-grekas
Copy link
Member

nicolas-grekas commented Oct 5, 2018 •
edited
Loading

I'm 👎 here: data transformers are not where strictness should apply. Strictness is for validators.
My reasoning is "why?" should we make this change? What would it improve? On the maintainer side, nothing. On the user side, it would just make using the HTTP endpoint less compatible with UI widgets into the wild, thus making things harder to use actually.
Same as why XML didn't win the race and browsers are using a loose HTML5 parser for the benefit of the robustness of the Web.

@nicolas-grekas
Copy link
Member

@xabbuh ok with my main objection: not worth adding a new option as DX may suffer?

@xabbuh
Copy link
Member Author

xabbuh commented Feb 16, 2019

I am closing here for now. We can consider to reopen when we notice that a less strict date format handling leads to avoidable bugs.

@xabbuh xabbuh closed this Feb 16, 2019
@xabbuh xabbuh deleted the datetime-strict-html5-format branch February 16, 2019 11:46
@nicolas-grekas nicolas-grekas modified the milestones: next, 4.3 Apr 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@stof stof stof left review comments

Assignees
No one assigned
Labels
Deprecation Form Status: Needs Review
Projects
None yet
Milestone
4.3
Development

Successfully merging this pull request may close these issues.
4 participants
@xabbuh @nicolas-grekas @stof @carsonbot