DateType storing wrong format date

[shakaran]

Q	A
Bug report?	yes
Feature request?	no
BC Break report?	yes
RFC?	no
Symfony version	3.3.10

I am using a custom type based in DateType and when it stores the date in the database is changing the format, even if I indicate the format in the widget.

This is my code:

<?php

namespace MyApp\Form\Type;

use Symfony\Component\Form\AbstractType;
use Symfony\Component\OptionsResolver\OptionsResolver;
use Symfony\Component\Form\Extension\Core\Type\DateType;
use Symfony\Component\Form\Extension\Core\Type\TextType;

class DatePickerType extends AbstractType
{
    public function configureOptions(OptionsResolver $resolver)
    {
        $resolver->setDefaults(
                [
                    'data_class' => null,
                    'widget' => 'single_text',
                    'format' => 'dd/mm/yyyy', // Note here, it will change to default {{ year }}{{ month }}{{ day }} but dd/MM/yyyy will work
                                'html5' => FALSE,
                                'input' => 'datetime',
                                'model_timezone' => 'Europe/Madrid',
                                'view_timezone' => 'Europe/Madrid',
                                 'attr' => [
                                ]
                 ]
                );
    }

    public function getParent()
    {
        return DateType::class;
    }
}  

Note that using 'format' => 'dd/mm/yyyy' will fail because this line that make a preg_match it is not parsing or taking in mind the month in lowercase format and resulting as fallback as {{ year }}{{ month }}{{ day }} which stores in database like yyyy-MM-dd, so I always get corrupted the month value.

So a possible fix could be allow "M" or "m", thats is (M|m) in the regex:

if (preg_match('/^([y(M|m)d]+)[^y(M|m)d]*([y(M|m)d]+)[^y(M|m)d]*([y(M|m)d]+)$/', $pattern)) {
                $pattern = preg_replace(array('/y+/', '/M+/', '/d+/'), array('{{ year }}', '{{ month }}', '{{ day }}'), $pattern);
            }

[Simperfit]

As i'm reading the comments on the preg_match, I followed the link for ICU, if you look at this, it will tell you that you will need to use MMM or MMMM, for exemple you can look at the test about MMM in de_AT

[shakaran]

@Simperfit interesting, the problem is that Symfony don't throw or log any message falling in the fallback case, so I didn't notice this until I debug or experience problems with corrupted data in applications. It would be nice if Symfony add at least some warning or even throws a exception if the format is invalid or don't verify the ICU format

[Simperfit]

What could be the best behaviour here ? I guess throwing will be a little too much, just logging a warning maybe the same type when the translation is missing ?

Something like, 'The DateTime format %s is not supported in ICU falling back to default format.'

[shakaran]

@Simperfit yep, logging the warning at least could be more easily to detect in development or production for avoid the data loss or wrong dates set

[Simperfit]

@shakaran Could you provide the PR adding this behaviour ?

[shakaran]

@Simperfit it seems that you already address some PR to that with trigger_error, which could be a nice solution unless that someone purpose other way to do it

[ostrolucky]

Hold on, something doesn't add up here.

You have specified single_text as widget option. Code you linked is evaluated only if formatter option is set. And formatter option is set only if widget is not set to single_text.

[Simperfit]

@shakaran Could you please look what @ostrolucky said, it seems that's more of a misunderstanding than a bug.

[shakaran]

@ostrolucky @Simperfit my intention is clear. Use single_text as widget and user formatter option set. I think that it is not a misunderstanding.

The formatter option is set in my code as:

'format' => 'dd/mm/yyyy'

And not:

'format' => 'dd/MM/yyyy'

The regex in the code will not allow "m", only "M".

So if a user puts "m", at least needs trigger a user error or something because if not it is very difficult to detect the data loss in database, because it will be fallback converted

[ostrolucky]

@shakaran I wasn't talking about format option, but formatter attribute.

Once again, this block is not supposed to be executed in your case, because that condition fullfills only when this line executes And that whole branch is executed only for non single_text widgets. So this is impossible to reproduce for us with given information. Are you able to create a small example application that allows to reproduce your issue?

[xabbuh]

I am going to close here for now due to the lack of feedback. Please let us know when you have more information and we can consider to reopen.