Datetime element formats are confusing

The docs say:

#date_date_format: A date format string that describes the format that should be displayed to the end user for the date. When using HTML5 elements the format MUST use the appropriate HTML5 format for that element, no other format will work. See the format_date() function for a list of the possible formats and HTML5 standards for the HTML5 requirements. Defaults to the right HTML5 format for the chosen element if a HTML5 element is used, otherwise defaults to

You should be able to work round this without too much difficulty in a custom widget extending one of the core widgets.

I had same issue, here is the link which one useful to change​ the date format Datetime widgets

Expanding on #3, this is really a problem of the docs being in a weird place for this form element. Per

https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Datetime%...

if you use the HTML5 form elements (which are only supported in some browsers, others make them behave like text fields), then the date/time formats *have* to be the HTML5 flavors ('Y-m-d' and 'H:i:s'). And per Datetime::getInfo(), they default to the HTML5 inputs when not specified.

If you want to use your own formats, you have to explicitly make the form elements 'text'. The following should work:

$form['datetime'] = [
  '#type' => 'datetime',
  '#size' => 20,
  '#date_time_element => 'text',
  '#date_date_format' => 'd/m/Y',
  '#date_time_element' => text',
  '#date_time_format' => 'H:m',
];

This topic has come up enough times that I think we need a better solution here. I think there are a few (potentially not mutually exclusive) options here:

- Improve the docblocks and/or move some of the information around, perhaps much on Datetime::processDatetime() should be moved to the top level comment on the class (and some of that may not be accurate in Drupal 8 anymore).
- Trigger a notice when custom formats are specified with the HTML5 elements.
- If a custom format is specified, then force the element to 'text' (not keen on this, and it has probably has BC consequences).

Open to other suggestions. I like the first two.

if we applied '#date_time_element => 'text' attribute, date_popup is not displayed but we need to date_popup feature also.

I don't really understand what you need here. If you're using a popup, why care about format?

Anyway, the issue queues for Drupal core aren't typically the best place for support questions around the details of your specific workaround. To get more support, I suggest you post a detailed question on Drupal answers.

#6 is a good direction for this issue, I'll update the IS to fit that.

#11, can you explain a little more why you need the popups and your own custom format? The custom format is used to parse the input, but if it is coming from the popup, it isn't needed. If you need the date in another format in code, you can just convert it in your submit handler.

#13, in your submit handler `$form_state->getValue('datetime') will be a DrupalDateTime object built from the date/time in your form. You can use that directly, or if you need the 'd/m/Y', you can just `$form_state->getValue('datetime')->format('d/m/Y')`

#15, per https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date

One thing to note is that the displayed date format differs from the actual value — the displayed date format will be chosen based on the set locale of the user's operating system, whereas the date value is always formatted yyyy-mm-dd

.

Drupal 8 uses HTML5 input elements, so the date popup is either from the browser itself with those that support it (eg, Chrome, iOS) or the polyfill from those that don't (eg, Firefox but not 100% sure if that is still the case). Drupal 7 uses text inputs w/ the jQuery UI library for the popup.

If you want the popup, you aren't going to be able to use `'#date_date_format' => 'd/m/Y'`. You will need to retain the 'Y-m-d' format in the $form element, and then convert the value to 'd/m/Y' in the submit handler. My working code for this is on my other machine I; I will post a sample later.

I suspect these are display formats that will depend on the browser's locale. This fiddle might help you explore this behavior: http://jsfiddle.net/to311fj5/

You may be able to avoid this if you don't use the core datetime (HTML5) element but instead a jquery datepicker. But please discuss that on Drupal Answers, not here in the Core issue queues.

I'm trying to get this working, so that I can then update the documentation. Here's what I'm encountering thus far.

Trying an element like the following, which uses a custom date, and time, format, doesn't work.

    $form['datetime_custom'] = [
      '#title' => 'Custom format datetime element',
      '#type' => 'datetime',
      '#size' => 20,
      '#date_date_element' => 'text',
      '#date_date_format' => 'd/m/Y',
      '#date_time_element' => 'text',
      '#date_time_format' => 'H:i',
    ];

When the form is submitted, during validation, \Drupal\Core\Datetime\Element\Datetime::valueCallback is called to get the value of the field, which in turn uses \Drupal\Component\Datetime\DateTimePlus::createFromFormat. createFromFormat in this case throws an exception here:

      if ($settings['validate_format'] && $test_time != $time) {
        throw new \UnexpectedValueException('The created date does not match the input value.');
      }

This is because $test_time, and $time are not equal.

When you enter the value 4/3/1982 10:10 into the input field, it creates a valid DateTime object. Then, later in the method it runs this $test_time = $date->format($format); to get the test time. $format = 'm/d/Y H:i' from the element above. And you end up with $time = '4/3/1982 10:10' and $test_time = '04/03/1982 10:10' because m, and d, and H, and i all allow for optional leading zeros. So, the check fails, and expection is thrown, and the element doesn't validate. But ... it really should.

I think in addition to updating the documentation this problem should probably also be fixed.

Is any of this covered by documentation? Specifically, I had been trying to use a "date" form element (rather than "datetime" element) but seeing now that "date" element does not work correctly: #2944552: Documentation for #default_value in Date form element is incorrect.

Switching my element to "datetime" does work correctly, but, it displays time, which i do not want. Dying to know where documentation is so that I can disable time portion of field.

#24, oddly it's all on Datetime::processDatetime. See my comment on #6 about potentially moving this to a better place.

Hiding the 'time' element is possible.

I struggled with this like liquidcms in #24, as I was using the 'date' form element.

Docs here show you need to:

- use the 'datetime' field
- specify '#date_date_element' as 'date'
- specify '#date_time_element' as 'none'

Also, this allows you to set default value, which requires a DrupalDateTime object. The 'date' field will not accept a default value.

Thank you @brianwagner for your comment it is very handy :-)

Is this still relevant now that #2791693: Remove sample date from date field error message and title attribute is in?

Yes, this still is a DX problem.
In the contrib field Office Hours, maintainer each time struggles with this, whenever there is an issue with the HTML5 setting. For a 'modern' UX element, persons expect the 'ampm' time format to be supported. If this si not the case, this must be perfectly clear. Also, as stated above, the developers machine may not support all OS-version in the field.

To add a note: especially ampm vs. 24-hours notation and with: #2811507: Date hour format is hard coded and can't be override

#37
yes, this wider issue is still relevant. Core's date wow's are 'as tough to deal with as ever'
1 .as a dev working on client project. core date field/widgets lack in many many ways!!!!
2. as a user filling out date forms in drupal sites.. simple test 'all the date widgets' drupal provides, not just daterange (:

I agree that the datetime UI element needs work and that the am/pm format should be supported by default.

Updating tags per Issue tags field and Issue tags -- special tags and for issue #3565085: Drupal core issue tag cleanup.