@mktcode : Just to mention a pending discussion on the way we'll allow to specify sub-types labels:#20887 (comment)

Would it make sense to make all options of the subtypes configurable (i.e. add options likedate_options andtime_options)?

I just handled it like the widget options (date_widget andtime_widget) but on a second look making all subtype options configurable makes more sense I guess.

Configuring every sub-types options does not really make sense to me. You shouldn't care about most of them, whichare inherited or guessed within the parent type acting as encapsulation.

What's the status of this PR?

This PR is coherent with current handling of subtype options, so it seemed viable to me. On the other hand, in case of sub types, granting access to all of their options seems very legit too, but maybe this is a topic of its own.
So if it was my project I would merge and start a separate discussion on sup type options. But(!) as I am not that much into it maybe I don't get the whole picture.

+1 for accessibility reasons (http://webaim.org/techniques/forms/controls#input)
it will often make sense to visually hide the labels for time, so label_attr will also be needed to supply the appropriate class for that.

form rows:
Even on smallest screens you will want both fields to be displayed in one row (side by side)
wrapping each part of datetime in a separate div makes this difficult to handle though.

Personally I use this SO solution for form row atributes on a regular basis in all of my projects.
https://stackoverflow.com/questions/23011450/symfony-twig-how-to-add-class-to-a-form-row
That gives you all css hooks needed to make
{{ form_start(form) }} {{ form_widget(form) }} {{ form_end(form) }}
a viable way to render a form without any tweaking in the template.
Maybe that should be part of the standard symfony form component, but that would be another issue, i guess.

Thinking about this again the proposed solution looks good to me and is in line with the existingdate_widget andtime_widget options.

@mktcode Can you check the failure and make fabbot happy?

@xabbuh@fabpot patch applied

@xabbuh@fabpot will this PR ever be merged (or closed)? I would like to see my PR list empty again. :D

Thank you@mktcode.

@mktcode thanks! We've createdsymfony/symfony-docs#10292 to not forget about documenting this new feature. If you want to give it a try, we can help you as much as you need in the Symfony Docs repository. Thanks!