Closed braianj closed 1 year ago
### Update
With 'format' => \IntlDateFormatter::LONG
solve my problem but 'format' => \IntlDateFormatter::MEDIUM
is not working
Hi,
I've encountered this issue and I have some steps to replicate the issue in pure PHP and I kind of know why it happens, but not how to solve it.
So, basically, Sonata relies on IntlDateFormatter
, which follows a date format standard called ICU
( https://www.php.net/manual/en/class.intldateformatter.php#intldateformatter.seealso ).
In Spanish, the ICU standard expects the month of September in MEDIUM
format to be sept.
. But Sonata is sending sep.
(notice the missing t
).
Here is a single script where you can see how it works with sept.
, how it fails with sep.
and how it converts a September timestamp to sept.
:
<?php
$dateFormat = \IntlDateFormatter::MEDIUM;
$timeFormat = \IntlDateFormatter::NONE;
$timezone = "Europe/Berlin";
if (class_exists('IntlTimeZone', false)) {
$timezone = \IntlTimeZone::createTimeZone($timezone);
}
$calendar = \IntlDateFormatter::GREGORIAN;
$pattern = null;
$locale = 'es';
$intlDateFormatter = new \IntlDateFormatter($locale, $dateFormat, $timeFormat, $timezone, $calendar, $pattern);
$intlDateFormatter->setLenient(false);
$dates = ["12 sept. 2019", "12 sep. 2019",];
foreach ($dates as $date) {
$data = $intlDateFormatter->parse($date);
print_r($data);
print "\n";
if (!$data) {
print_r($intlDateFormatter->getErrorMessage());
print "\n";
}
}
print $intlDateFormatter->format(1568332800);
print "\n";
This is the why it is happening. But I am not sure from where it comes. It could be PHP, as date('m', 1568332800);
returns Sep
that it is not a valid month for the ICU standard.
It could be in the javascript date picker, as javascript usually generates sep
too:
var event = new Date(2019, 8, 12, 14, 39, 7);
console.log(event.toDateString());
By default, the date format used is \IntlDateFormatter::MEDIUM
, which causes the issue. I'm opening a PR to set other format by default in order to prevent this error for happening if no extra configuration is provided.
maybe @ro0nl our Intl-Expert can help us out here 🤔
i believe date formatting is more @xabbuh's domain :grin: in general; is it a BC break in Symfony? Are you using the IntlDateFormatter
stub from Symfony? otherwise something changed in PHP intl isnt it..
edit: nothing broke right (sorry im not a sonata user), but https://github.com/sonata-project/form-extensions/issues/362 shows an existing integration issue
The IntlDateFormatter
comes from this file from Symfony: https://github.com/symfony/symfony/blob/4.4/src/Symfony/Component/Form/Extension/Core/DataTransformer/DateTimeToLocalizedStringTransformer.php#L170
This DateTimeToLocalizedStringTransformer
is called from the Form
class itself here: https://github.com/symfony/symfony/blob/4.4/src/Symfony/Component/Form/Form.php#L1055
I do not know where is the Transformer
configured. I am new to Symfony and Sonata (this was my first time touching it). But I can see that Sonata uses the IntlDateFormatter
also in its code: https://github.com/sonata-project/form-extensions/blob/1.x/src/Type/BasePickerType.php#L71
I do not know if it is a backwards compatibility issue of Symfony, as I have inherited this project and we have not changed the version of Symfony or Sonata. On the other hand, the original report of the issue was from a year ago, so it does not seem to be due to a recent change.
I do not know how Sonata sets up the form type at all, but having some Intl date formatter involved when talking about a date picker looks at least a bit suspicious to me. Is there a special reason not to use the HTML datetime format for the data exchange (which as an added bonus would also allow to fall back to an HTML5 datepicker when JavaScript is disabled)?
The default DatePicker form type of Sonata includes this javascript date picker. You can see the documentation here: https://sonata-project.org/bundles/core/master/doc/reference/form_types.html#datepickertype-datetimepickertype
DatePickerType / DateTimePickerType
Those types integrate Eonasdan’s Bootstrap datetimepicker into a Symfony form. They both are available as services and inherit from date and datetime default form types.
Here is the library: https://github.com/Eonasdan/bootstrap-datetimepicker
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
Still relevant and not solved
With format Long it also doesnt work (even other months stop working) Format - Short is working, it looks like: d/mm/YY
Wanna work on this @bochkarev-artem ?
If this is a problem, I think the issue is in the way the comparison is implemented. By instance, using the locale "es_ES" (Spanish from Spain) the month representation is "sept.", while using "es_AR" (Spanish from Argentina) the representation is "sep.". I think this is the expected behavior from the ICU perspective.
@DavidHernandez, could you please elaborate this affirmation regarding the ICU standard?
This is the why it is happening. But I am not sure from where it comes. It could be PHP, as date('m', 1568332800); returns Sep that it is not a valid month for the ICU standard.
You could check if the right "locale" option is passed to Sonata\Form\Type\BasePickerType
:
$view->vars['dp_options'] = $dpOptions;
since this option is intended to provide the "locale" option in the template:
$('#{{ datepicker_use_button ? 'dp_' : '' }}{{ id }}').datetimepicker({{ dp_options|json_encode|raw }});
Looking at bootstrap datepicker, its clear that locale
is controlling the language and format: https://jsfiddle.net/iamraviteja/xnxc4awv/2/
But when i try to apply this code in sonata admin i see only english version. In order to load correct language you need to specify language
option (Btw. its language
option in getCommonDefaults() of Sonata\Form\Type\BasePickerType).
Hardcoding language doesnt take any effect. Here i print content of dp_options
in src/Bridge/Symfony/Resources/views/Form/datepicker.html.twig
(locale is set by browser's language and language
option is hardcoded on backend):
Maybe this fixes the issue: https://github.com/sonata-project/form-extensions/pull/427
Since we are jumping 3 majors and its not even using same library (moment was dropped on the date picker) this issue will be closed. If the problem persist, we should update a bit the issue to reflect how it is seen with the new version.
Environment
Sonata packages
Symfony packages
PHP version
Subject
When I send any day of any year with september as a month it's not getting the date.
Steps to reproduce
First I make a composer update. I'm using sonata admin and setted up the config file with:
and
Expected results
Actual results