symfony: [Form] Do not fail reverse transforming relative dates

Description

Since v2.8.46, relative dates are not supported anymore by DateTimeType.

I am guessing this is because of the patches :

bug #28466 [Form] fail reverse transforming invalid RFC 3339 dates
bug #28372 [Form] Fix DateTimeType html5 input format

It would be great to introduce the feature again by adding a dedicated value of the format option, or anything better you can think of.

Example

At @lrqdo, the relative dates are helping us simplify our Behat scenarios.

Here is an example of a Behat scenario failing on v2.8.46:

When I send a POST request to "/endpoint" with values:
  | distributionDate | +14 days |
Then the response code should be 200
  Failed asserting that 400 is identical to 200.

Here is the form type we wrote:

public function buildForm(FormBuilderInterface $builder, array $options)
{
    $builder->add(
        'distributionDate',
        DateTimeType::class,
        array(
            'widget' => 'single_text',
        )
    );
}

And here is the detailed error we get:

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 3
Comments: 22 (15 by maintainers)

Most upvoted comments

@horlyk It’s actually weird that your code ever used to work. The date_format option is only meant to be used when the widget option is not single_text as this is what is then passed to the nested DateType (see ). In your case, using the format option is the way to go. Just be careful that the format is must use the ICU syntax:

->add('startDate', DateTimeType::class, [
    'widget' => 'single_text',
    'date_format' => 'dd-MM-yyyy HH:mm',
    'html5' => false,
    'label' => false,
])

I am still going to take a look into why this worked before.

xabbuh on Oct 4, 2018

From my point of view this never has been a supported use case and only worked “accidentally”.

xabbuh on Oct 3, 2018

I am closing here as using relative dates has never been a supported use case and as @stof explained we better not want to support everything the DateTime constructor accepts. The other issues discussed here look like duplicates/variants of #28699 which has been fixed in the meantime.

xabbuh on Oct 31, 2018

@horlyk I think we can improve DX here (#28721 is the first step in that direction)

xabbuh on Oct 4, 2018