Problem here is a bit more complicated IMO.

DateType don't uses empty_data, it's uses empty_value, and IIRC only in case when 'choice' === $options['widget']. But even in this case that empty_value with value of new \DateTime() would probably fail.

According to twitter conversation with @bschussek it seems to be a bug. Also why does this type use empty_value and not empty_data.. Futhermore empty_value dosent have an impact.

@stloyd "empty_data" and "empty_value" are two completely different options

Should we maybe rename "empty_value" to "placeholder" in order to clarify the difference?

This problem is not easy to solve. The problem is that the "empty_data" doesn't exactly solve this case, but a slightly different one.

When a form is bound, the data of the form's children is mapped into the form's data in view format and then reverse transformed to the normalized and model format. An illustration of this process:

+-------+         +-------+         +-------+
| Model |         | Norm  |         | View  | <----- child data
+---+---+         +---+---+         +---+---+
    |                 |                 |
    |                 |                 |
    |                 |                 |
FormType:             |                 |
    |                 |                 |
<------------------------------------ null
<------------------------------------ array 
<------------------------------------ object
    |                 |                 |
DateType:             |                 |
    |                 |                 |
<------------------------------------ null
<---------------- DateTime <.           |
    |                 |      }------- array 
<------------------ null <--´           |

1. When a form of type FormType is bound, the child data is written into the view data. When the view data is null, an appropriate view data needs to be created first (array or object). Then the reverse transformation starts.

2. When a form of type DateType is bound, the bound array is either transformed to null (if the array has only empty values) or to DateTime otherwise. After the reverse transformation, you now want to convert null to your DateTime.

As you can see, 2) is a totally different case than 1). The only solution I see right now is to add a model transformer that converts null to a new DateTime.

I'll leave this ticket open as we need to address this issue in 2.2.

This one has been closed automatically and has to be reopened.

I did this http://vandpibe.bjrnskov.dk/index.html#nulltodatetimetransformer and can be found here http://github.com/vandpibe/form

@webmozart what is your current PoV regarding this issue ? should we add the ModelTransformer ?

Just tried to fix this again using a DataMapperInterface implementation (DateTimeMapper), but that's difficult because "empty_data" specifies the data in view format (depends on widget), and not in normalized format. I don't think this can be fixed without some major changes.

Hi, it's a problem that this bug isn't solved for the moment...
But, I find a solution in case of a form build with an entity.

In this case, I set default dates when I create a new entity but I don't when this is the edit case because I want dates fields are filled with stored data.

If you don't specify the 'data' attribute of a DateType, the field will be empty.

This will replace the functionning of "empty_data".

<?php

namespace AppBundle\Form;

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

class MyEntityType extends AbstractType
{
    public function buildForm(FormBuilderInterface $builder, array $options)
    {
        $beginOptions = array(
            'label'     => false,
            'widget'    => 'single_text',
            'html5'     => false,
            'format'    => 'yyyy-MM-dd',
        );

        $endOptions = array(
            'label'     => false,
            'widget'    => 'single_text',
            'html5'     => false,
            'format'    => 'yyyy-MM-dd',
        );

        // Case : new entity
        if (empty($options['data']->getId())) {
            # default dates
            $beginOptions['data'] = new \DateTime('now');
            $endOptions['data'] = new \DateTime('tomorrow');
        }

        $builder
            ->add('beginDate',  DateType::class, $beginOptions)
            ->add('endDate',    DateType::class, $endOptions)

            // [...]
        ;
    }

    public function configureOptions(OptionsResolver $resolver)
    {
        $resolver->setDefaults(array(
            'data_class'  => 'AppBundle\Entity\MyEntity',
        ));
    }
}

Hello, any news for this issue?

Hello there!

As explained above, this is not a bug, but an annoying limitation.
In both case the behavior we expect here is not right.

Usually, I'm in favor of fixing the docs and making such behavioral change in master.
But I think this case is different because what we're actually dealing with is an inconsistency in the way empty_data (a.k.a default view data on submission) is handled; which is not the same depending on the widget of all date related types, because basically it depends on whether the form is compound.

1/ If the form uses the choice or the text widgets, then it's compound so its empty data is an empty array no matter what. Because in a compound field, the view data is the data into which default inner fields model data should be mapped.

2/ If it uses the single_text widget then the empty data value is reversed transformed to a \DateTime object as expected (see test added in #29179). Because in a simple field, the view data is the one replacing the model data.

So if we want to fix 1, we need to cascade the configuration to inner fields to be able to set values used as default. This should not be a problem since this never worked as expected before.

I suggest we do it in 2.8, here's a proposal #29182.