-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Form] DateType fails parsing when midnight is not a valid time #19531
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
Comments
For reference, I've closed the php.net bug as ICU returns an error and there's little we can do in the intl extension. Sure, ICU could be smarter, but its behaviour can't be altered. In any case, think that the error lies in the way the date is parsed though. Since we're not talking about date+time, the date-only should be parsed using UTC, then eventually converted to a \DateTime in the local timezone, e.g.: https://3v4l.org/WivPk |
Thanks for the PR!! Status: reviewed |
…not a valid time (mbeccati) This PR was merged into the 2.7 branch. Discussion ---------- Fix #19531 [Form] DateType fails parsing when midnight is not a valid time | Q | A | ------------- | --- | Branch? | 2.7 | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #19531 | License | MIT | Doc PR | Commits ------- c951bb6 Fix #19531 [Form] DateType fails parsing when midnight is not a valid time
Thanks @fabpot |
* 2.7: [Routing] Add missing options in docblock [VarDumper] Fix dumping continuations [HttpFoundation] fixed Request::getContent() reusage bug [Form] Skip CSRF validation on form when POST max size is exceeded Enhance the phpDoc return types so IDEs can handle the configuration tree. fixes Remove 3.0 from branch suggestions for fixes in PR template [Process] Strengthen Windows pipe files opening (again...) Fix #19531 [Form] DateType fails parsing when midnight is not a valid time
* 2.8: [Routing] Add missing options in docblock [VarDumper] Fix dumping continuations [HttpFoundation] fixed Request::getContent() reusage bug [Form] Skip CSRF validation on form when POST max size is exceeded Enhance the phpDoc return types so IDEs can handle the configuration tree. fixes Remove 3.0 from branch suggestions for fixes in PR template [Process] Strengthen Windows pipe files opening (again...) Fix #19531 [Form] DateType fails parsing when midnight is not a valid time
* 3.1: [Routing] Add missing options in docblock [VarDumper] Fix dumping continuations [PropertyInfo] Fix an error in PropertyInfoCacheExtractor [HttpFoundation] fixed Request::getContent() reusage bug [Form] Skip CSRF validation on form when POST max size is exceeded Use try-finally where it possible [DependencyInjection] ContainerBuilder: Remove obsolete definitions Enhance the phpDoc return types so IDEs can handle the configuration tree. fixes Remove 3.0 from branch suggestions for fixes in PR template [Process] Strengthen Windows pipe files opening (again...) [Cache] Handle unserialize() failures gracefully Fix #19531 [Form] DateType fails parsing when midnight is not a valid time
After merge, there is bug on the DateTimeType::class form type - DateTimeToLocalizedStringTransformer class on branch master. My timezone is Europe/Warsaw, +2h from UTC timezone. Part of form:
When for example publishDateEnd is set as 2016-08-01 10:00:00 and I set in the web form date as 2016-08-01 12:00:00, after save form date back to 2016-08-01 10:00:00. Should be saved as 2016-08-01 12:00:00. When I add 'view_timezone' => 'UTC' into widget option, date is set as correct date. |
@dkorsak can you please open a new issue? |
In some timezones, midnight may not be a valid date; this happens when the DST change was done on midnight. It's a poor choice, and it was done only in the past. If you enter those dates in a
DateType
, it gets rejected as invalid.Under the hood, the issue is with the
\IntlDateFormatter
that is initialized with the current timezone, when with a simple date it can be avoided... Here: https://github.com/symfony/symfony/blob/3.1/src/Symfony/Component/Form/Extension/Core/DataTransformer/DateTimeToLocalizedStringTransformer.php#L119Maybe decoupling between DateType and DateTimeType could be a solution?
In my case, TZ is
Europe/Rome
and one of the infamous date is1978-05-28
; I can reproduce the issue in this 3val: https://3v4l.org/NDnbmDateTime doesn't suffer this bug: https://3v4l.org/ZmQ1q
Mainly, the Form uses the intl extension, that uses ICU, and that assumes midnight as the hour if not specified, which is what happens when you use a
DateType
field.I tried to open a bug on https://bugs.php.net/bug.php?id=72649 but it got closed... What can we do about it?
PS: this issue surfaced already multiple times: #18267 #16518 #16368
The text was updated successfully, but these errors were encountered: