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
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | time-field-inserting-a-blank-space-3334279-5.patch | 771 bytes | alex.skrypnyk |
Issue fork date-3334279
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
Comment #2
damienmckennaI'm sorry we inadvertently broke something in the new release.
Comment #3
christian deloach commentedUpdated 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: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!
Comment #4
damienmckennaComment #5
alex.skrypnykTemporary patch to remove prefix as per #3 attached.
Comment #6
rclemings commentedI'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?
Comment #7
damienmckennaIt might be worth adding a widget setting to control this.
Comment #8
jayemel commentedI 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.Comment #9
codesmithWorkaround in #8 worked for me - thanks!
Comment #10
desierto commentedThe 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.
Comment #13
jimmynash commentedJust chiming in. Patch in #5 fixed me right up. Thanks!
Comment #14
vali hutchison commentedPatch in #5 fixed the issue for me too.
Comment #15
argiepiano commentedPatch #5 fixed it for me too.
Comment #16
shivam_tiwari commentedComment #17
awasson commentedWorkaround in #8 worked for me too - thanks @jayemel
Comment #18
steinmb commentedPushing it back to NW based on maintainer feedback in #7, though I am not 100% sure if this really needed?