Date field validation broken after update to 7.x-2.11

You might want to look at this post: https://www.drupal.org/project/date/issues/3202956

Also looking at your element code, if you have date format of d M Y - g:i a, I would expect this might cause a validation error due to the space between minutes and am/pm designation if you entered the value without a space?

I just ran into this myself. It is triggered on the date_text widget.

The "all-day" fix has been moved into the 7.x-3.x branch.

Moving this to 7.x-3.0-beta2 so that we can get the core restructuring into beta1.

Can you please test the current 7.x-2.x dev snapshot, let us know if it solves the problems or if they still exist. Thank you.

I'm getting this issue with latest site_alert-7.x-1.x-dev and date-7.x-3.x-dev (as well as 2.x-dev).

Steps to reproduce:

Install site_alert.
Go to /admin/config/system/alerts
Create an alert with an Expiration date (because the date ranges are required, due to core limitations).
Hit this error message:

The value input for field Expiration date for Alert is invalid:
The value 11-17-2021 11:00 AM does not match the expected format.

Relevant code in site_alert module:

  $format = 'm-d-Y h:iA';
  $form['site_alert_expire'] = array(
    '#type' => 'date_popup',
    '#title' => t('Expiration date for Alert'),
    '#date_format' => $format,
    '#date_label_position' => 'within',
    '#date_increment' => 15,
    '#date_year_range' => '-1:+1',
    '#default_value' => variable_get('site_alert_expire', $date),
    '#date_timezone' => variable_get('date_default_timezone', 0),
    '#required' => TRUE,
    '#suffix' => '<div class="site-alert-date-info">' . '<em>' . t("Dates are stored in the site's default timezone, currently %tz", array('%tz' => variable_get('date_default_timezone'))) . '</em></div>',
  );

Which produces the following element:

The only difference I see is that there is a space between the am/pm in the field, but not in the example description text below the field. This is also exactly what is mentioned in comment #2 above.

The site_alert module explicitly sets the format as m-d-Y h:iA.

If I change the site_alert module to have a space between the time and the am/pm, it works.

So it seems the bug is with date_popup not actually supporting #date_format without a space between the time and am/pm.

I've created an issue on site_alert module #3249811: Site_Alert 7.x date_popup compatibility so that I can easily patch this without digging into date_popup and #date_format validation internals.

I am confused about the space theory. The problem is happening in date_api.module in the function parse($date, $tz, $format) {} line 613 and following. The logic to create $regex1 is not properly including any time value that is present in the input $date. So then the comparison with $regex2 only is checking m-d-Y when I also have m:s AM in the input date.

Here are actual input and resulting values from a failed call to parse() at the time of the error message on line 649.

$date = "01-01-2022 04:09 AM"
$regex1 = "(.)\-(.)\-(.)"
$letters = Array([0] => m, [1] => d, [2] => Y)
$regex2 = "(\d{1,2})\-(\d{1,2})\-(-?\d{1,6})"
$values = Array()

So the date parse() function is failing to add the time into $regex1.

Any of the module contributors around to debug this further?

Further testing and yes it does have something to do with whether or not a space is specified in the format string before the AM/PM indicator. In my test the failing date was from the 'scheduler' module which allows me to specify the format of the scheduled date. My format was "m-d-Y h:iA" with NO space before the "AM/PM". However when the date_api.module parse() function was called the format string was "m-d-Y h:iA" as expected, but the date was "01-01-2022 04:09 AM" with a space before "AM/PM". Thus, the comparison of the $date with the format failed.

The quick fix was to add a space in my format string "m-d-Y h:i A" for the scheduler module.

Probably the same error was the original poster because I am using date popup also. Apparently Date Popup always puts space before "AM/PM" regardless of the format specified.

So I have a work around, but this is not truly fixed.

Hmmm. Perhaps we needs tests or if there is tests they need to be improved/extended?

Thanks for working on the merge request. I re-ran the branch tests to confirm that the test failures are not existing problems and they worked fine, so unfortunately these are legit regressions in the change.

Seems to me that the problem is simple.

In the parse() function the $regex1 and $regex2 values distinguish between a space or no-space before the AM/PM indicator. So if the $date argument has a space or has no-space before AM/PM BUT the $format string is the opposite then the parse() function will flag an error.

So the question is whether this should be an error. If not, then fix parse() to allow this difference.

If it is supposed to be an error then fix date popup which does not respect the $format string and only ever puts a space before AM/PM.

Thank for your swift reply and for taking the time re-running tests. Sorry for the noise in the issue. Still learning how the gitlab integration works. The second commit it pushed after I created the pull req. did not show up, hence the second pull req. Must have pushed to wrong branch some.

git remote -v
fork	git@git.drupal.org:issue/date-3204114.git (fetch)
fork	git@git.drupal.org:issue/date-3204114.git (push)
origin	https://git.drupalcode.org/project/date.git (fetch)
origin	https://git.drupalcode.org/project/date.git (push)

git branch -vv
* 3204114-date-field-validation 0c22f2c9 [fork/3204114-date-field-validation] DateObject::extract_letters() did not return AM/PM.
  7.x-2.x                       3150217b [origin/7.x-2.x] Issue #2779769 by DamienMcKenna, CoderBrandon: Time zone handling for Site's time zone settings incorrectly sets tz to user's.

git log 7.x-2.x.. --oneline
0c22f2c9 (HEAD -> 3204114-date-field-validation, fork/3204114-date-field-validation) DateObject::extract_letters() did not return AM/PM.
963166be (fork/7.x) Extract to function date letter matching

In patch format.

I am facing the same issue and sorry patch at #20 didn't fix that, I was trying with a simple test form at

function custom_test_form($form, $form_state) {
  $form = [];
  $form['lesson_date'] = [
    '#type' => 'date_popup',
    '#date_format' => 'l, M d Y h:iA',
    '#date_increment' => 15,
    '#title' => t('Lesson Date'),
  ];

  $form['submit'] = array(
    '#type' => 'submit',
    '#value' => t('Submit'),
  );
  return $form;
}

and I continue to get the error.

How I got it work is changing the format
'#date_format' => 'l, M d Y h:iA', changed to '#date_format' => 'l, M d Y h:i A',

i.e. just adding a space before the AM and PM

I noticed this that the parse function called has this space in the time part of value and our format don't that causes it to throw the error, not sure what the exact problem is, there is something buggy and needs a proper fix, I am commenting just as a quick fix for other developers.

Note that changing the form field key as "date" also causes the error to go away.

  $form['date'] = [
    '#type' => 'date_popup',
    '#date_format' => 'l, M d Y h:iA',
    '#date_increment' => 15,
    '#title' => t('Lesson Date'),
  ];

Thanks,
Sadashiv.

When am/pm were made translatable the am/pm prefix was accidentally enabled only for the uppercase versions. The fix is simply to add it back to the lowercase versions.

https://git.drupalcode.org/project/date/-/commit/5f49b8670fa1d76101b0808...

The main error that happens on the test run is:

20:25:18 TypeError: Argument 1 passed to DrupalWebTestCase::drupalLogin() must be an instance of stdClass, bool given, called in /var/www/html/sites/all/modules/date/tests/DateFieldTestBase.test on line 41 in DrupalWebTestCase->drupalLogin() (line 1299 of /var/www/html/modules/simpletest/drupal_web_test_case.php).

I suspect that happens because of this problem:

fail: [Role] Line 40 of sites/all/modules/date/tests/DateFieldTestBase.test:
Invalid permission administer date tools.

For some reason it isn't enabling the date_tools module.

In patch format.

Committed. Thanks everyone.

I just updated to 7.x-2.14 and I'm now getting this issue.

The value input for field When Start date is invalid:
The value 01/27/2023 09:15 pm does not match the expected format.

This is a content type with Date field type, Calendar popup, optional End Date but not enabled in this case.

Is this the same problem as this issue or should I open a new one? Seems like the fixes here broke things. I rolled back to 7.x-2.13 and changing the date works again.

Let's continue this in #3334279: Time Field Inserting a Blank Space.