Why sonata admin datepicker is not getting dates with september in spanish

[braianj]

Environment

Sonata packages

$ composer show --latest 'sonata-project/*'

sonata-project/admin-bundle              3.35.2 3.39.0 The missing Symfony Admin Generator
sonata-project/block-bundle              3.12.1 3.12.1 Symfony SonataBlockBundle
sonata-project/cache                     2.0.1  2.0.1  Cache library
sonata-project/core-bundle               3.11.1 3.11.2 Symfony SonataCoreBundle
sonata-project/datagrid-bundle           2.3.1  2.3.1  Symfony SonataDatagridBundle
sonata-project/doctrine-orm-admin-bundle 3.6.1  3.6.1  Symfony Sonata / Integrate Doctrine ORM into the SonataAdminBundle
sonata-project/exporter                  1.9.0  1.9.1  Lightweight Exporter library
sonata-project/intl-bundle               2.4.1  2.5.0  Symfony SonataIntlBundle
sonata-project/translation-bundle        2.3.0  2.3.1  SonataTranslationBundle

Symfony packages

$ composer show --latest 'symfony/*'

symfony/monolog-bundle     v3.3.0  v3.3.0 Symfony MonologBundle
symfony/phpunit-bridge     v3.4.11 v4.1.4 Symfony PHPUnit Bridge
symfony/polyfill-apcu      v1.8.0  v1.9.0 Symfony polyfill backporting apcu_* functions to lower PHP versions
symfony/polyfill-ctype     v1.8.0  v1.9.0 Symfony polyfill for ctype functions
symfony/polyfill-intl-icu  v1.8.0  v1.9.0 Symfony polyfill for intl's ICU-related data and classes
symfony/polyfill-mbstring  v1.8.0  v1.9.0 Symfony polyfill for the Mbstring extension
symfony/polyfill-php56     v1.8.0  v1.9.0 Symfony polyfill backporting some PHP 5.6+ features to lower PHP versions
symfony/polyfill-php70     v1.8.0  v1.9.0 Symfony polyfill backporting some PHP 7.0+ features to lower PHP versions
symfony/polyfill-util      v1.8.0  v1.9.0 Symfony utilities for portability of PHP codes
symfony/security-acl       v3.0.1  v3.0.1 Symfony Security Component - ACL (Access Control List)
symfony/swiftmailer-bundle v2.6.7  v3.2.3 Symfony SwiftmailerBundle
symfony/symfony            v3.4.11 v4.1.4 The Symfony PHP framework

PHP version

$ php -v

PHP 7.1.20-1+0~20180910100532.3+stretch~1.gbp17c613 (cli) (built: Sep 10 2018 10:05:33) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.1.20-1+0~20180910100532.3+stretch~1.gbp17c613, Copyright (c) 1999-2018, by Zend Technologies

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:

    sonata_intl:
      timezone:
        default: America/Argentina/Ushuaia

and

    twig:
        debug: '%kernel.debug%'
        strict_variables: '%kernel.debug%'
        form_themes:
            - 'bootstrap_3_layout.html.twig'
            - 'SonataCoreBundle:Form:datepicker.html.twig'

Expected results

    s5bab8a989fa81[fechaDesde]:26 sep. 2018
    s5bab8a989fa81[fechaHasta]:27 oct. 2018
    s5bab8a989fa81[fechaFinProhibicion]:1 dic. 2018

Actual results

    FechaDesde :
    FechaHasta :DateTime Object ( [date] => 2018-10-26 23:00:00.000000 [timezone_type] => 3 [timezone] => America/Sao_Paulo ) 
    FechaFinProhibicion :DateTime Object ( [date] => 2018-12-01 00:00:00.000000 [timezone_type] => 3 [timezone] => America/Sao_Paulo )

[braianj]

### Update With 'format' => \IntlDateFormatter::LONG solve my problem but 'format' => \IntlDateFormatter::MEDIUM is not working

[DavidHernandez]

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());

[DavidHernandez]

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.

[OskarStark]

maybe @ro0nl our Intl-Expert can help us out here 🤔

[ro0NL]

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

[DavidHernandez]

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.

[xabbuh]

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)?

[DavidHernandez]

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

[stale[bot]]

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.

[bochkarev-artem]

Still relevant and not solved

[bochkarev-artem]

With format Long it also doesnt work (even other months stop working) Format - Short is working, it looks like: d/mm/YY

[VincentLanglet]

Wanna work on this @bochkarev-artem ?

[phansys]

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.

See https://3v4l.org/ELTgM.

@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.

[phansys]

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 }});

[bochkarev-artem]

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):

[jordisala1991]

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.