Define #return_value_format for date_popup to set the form value

#1409120: Date format in views exposed filter does not respect configured format is similar. Linking here for reference.

Hi russellb,

Thanks for your interest in this issue. Are you a user of scheduler, or is this problem affecting a different module that you use? It would be useful to know, as that may lend weight to getting it fixed.

By the way, did you know that if you want to follow an issue, instead of the old days where you had to add a 'subscribe' post, you can now click the 'follow' button at the top of the issue. The benefit of this is that it does not send an email to everyone else who is already following the post. You can also unfollow by clicking the same button.

Jonathan

This problem was discovered during investigation for #1720338: Allow for no time field on date popup

Here is a patch against the latest date dev _7.x-2.6+2 (dated 2012-09-30). I hope you will consider looking at this, as it is preventing us from implementing more flexible options using Date Popup.

Thanks
Jonathan

Try again.

The three failed tests are because the tests did not complete, I think this is nothing to do with the patch. The same thing is happening on other issues too - see #1635810: Views filtering of optional end dates #20 and #21 https://drupal.org/node/1635810#comment-7575253 and #1856306: Undefined index: repeat in date_repeat_field_bundles() #12 https://drupal.org/node/1856306#comment-7227006

Date_migrate tests fail because 'Migration' class is not found, referenced in date_migrate.test line 44

Does anyone know how to get the tests fixed? It gives a false impression that the patch has a fault.

Jonathan

Re-rolled against 2.6+15. No code changed. Just wondering if the failing tests discussed in #7 and #9 have now been corrected.

OK, I realised that regardless of whether the original behaviour was intended or was an oversight, changing the current behaviour now will break many implementations. Hence here is a modified fix which uses a new attribute $element['#return_value_format']. If this is set the string value is returned in this format, but if it is not set the current default of DATE_FORMAT_DATETIME is used.

In date_popup_validate()

  // If the created date is valid, set it.
  $value = !empty($date) ? $date->format(DATE_FORMAT_DATETIME) : NULL;
  form_set_value($element, $value, $form_state);

becomes

  // If the created date is valid, set it in the form. Use the optional return
  // value format '#return_value_format' but default to DATE_FORMAT_DATETIME.
  $return_value_format = !empty($element['#return_value_format']) ? $element['#return_value_format'] : DATE_FORMAT_DATETIME;
  $value = !empty($date) ? $date->format($return_value_format) : NULL;
  form_set_value($element, $value, $form_state);

Patch against 2.6+15

Jonathan

fixed spelling mistake

I would say that it was an oversight that was missed during development (so appears like a bug now) but it is too late to change the existing behavior because third-party modules may rely on it. Hence adding a new attribute will allow those who want to have the date returned in the matching format to get it, but the default behavior is not changed.

Jonathan