Problem/Motivation

We have a number of content types that use Date to populate our calendar, etc. After updating to 7.x-2.14 any changes to the time generates the error message of:

The value input for field Date Start date is invalid:
The value 03/16/2023 06:30 pm does not match the expected format.

This happens if we clone from existing content or create new content.

Steps to reproduce

1. Open a content type that uses Date
2. Upon opening the time field displays the time as: 12:30am (no space)
3. As you toggle to the time field the time changes to create a space between the number and the letters: 12:30 am
4. Save the work and you get the error message above.

If you do not make any changes to the time field then there is no error message.

Proposed resolution

Fix the bug.

Remaining tasks

Work out the source of the bug.
Add test coverage.

User interface changes

TBD

API changes

TBD

Data model changes

n/a

Issue fork date-3334279

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

Ne Sar created an issue. See original summary.

damienmckenna’s picture

Issue summary: View changes
Priority: Critical » Major
Parent issue: » #3333562: Plan for Date v7.x-2.15

I'm sorry we inadvertently broke something in the new release.

christian deloach’s picture

Updated the module from 7.x-2.13 to 7.x-2.14 yesterday and came across this issue. I suspect it due to patch in https://www.drupal.org/node/3204114. When I remove the new line added by the patch the date field works - no validation error.

I don't have much knowledge on the history of this module but it appears based on the comments in issue 3204114 the fix may have been to remove $settings['ampmPrefix'] = ' '; from:

if (strpos($element['#date_format'], 'A') !== FALSE) {
  // Then we are using uppercase am/pm.
  $options = date_ampm_options(FALSE, TRUE);
  $settings['ampmNames'] = array($options['am'], $options['pm']);
  $settings['ampmPrefix'] = ' ';
}

Please note the uppercase "A" in the strpos() test. However, I don't know what regressions may be caused by removing that setting. It looks like that was added back in 7.x-2.11-rc1 (see https://www.drupal.org/node/2359653).

For what it's worth, if you can't or don't want to patch the module yourself, a possible quick "fix" to get around this issue may be to configure the Date Popup module (Administration » Configuration » Date API) to use "Manual time entry, no jQuery timepicker". Disabling the jQuery timepicker turns the input field to a regular textfield. Unfortunately, now it's on the user to make sure they format the time correctly. But it's a quick work-around to avoid issues with administrators editing content and receiving an error about the format of a once valid date that cannot be corrected until a new release is available to address this issue.

Thank you Ne Sar for the post (glad it wasn't just me) and thank you DamienMcKenna!

damienmckenna’s picture

alex.skrypnyk’s picture

Temporary patch to remove prefix as per #3 attached.

rclemings’s picture

I'm not seeing this with PHP 8.1, Drupal 7.94, Date 7.x-2.14. Could it somehow be related to the PHP version?

damienmckenna’s picture

Status: Active » Needs work

It might be worth adding a widget setting to control this.

jayemel’s picture

I ran into this. Clicking the time field input adds a space before am/pm. if the "accepted format" on the field doesn't have a space, then it will fail.

A workaround:
The accepted format is configurable on the date field under "Date entry options". The default formats in that dropdown do not have a space before am/pm. But you can add your own format options to that dropdown under: /admin/config/regional/date-time/formats. E.g. Add a new format with a space before am/pm "M d, Y - g:i a". Then set this as your "accepted format" on the field.

codesmith’s picture

Workaround in #8 worked for me - thanks!

desierto’s picture

The patch in #3 and #4 fixed the problem right up. Hopefully the next version can come out soon to save a lot of headaches, esp. for the less techie. Thanks for everyone's work.

kunal_sahu made their first commit to this issue’s fork.

jimmynash’s picture

Just chiming in. Patch in #5 fixed me right up. Thanks!

vali hutchison’s picture

Patch in #5 fixed the issue for me too.

argiepiano’s picture

Patch #5 fixed it for me too.

shivam_tiwari’s picture

Status: Needs work » Needs review
awasson’s picture

Workaround in #8 worked for me too - thanks @jayemel

steinmb’s picture

Version: 7.x-2.14 » 7.x-2.x-dev
Status: Needs review » Needs work

Pushing it back to NW based on maintainer feedback in #7, though I am not 100% sure if this really needed?