Closed (cannot reproduce)
Project:
Date
Version:
7.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Reporter:
Created:
23 Sep 2011 at 19:32 UTC
Updated:
7 Dec 2011 at 13:01 UTC
Jump to comment: Most recent file
The issue does not happen on date insert, but on updating a node that has been saved with the value of 12:00am. From my initial browsing in order to fix this issue, it is because certain validation checks are being checked upon the form submit with the hour:minute:am/pm of 12:00am. If you submit the field with no value, edit the node again and put in another time, it works just fine.
Delving a bit deeper, the incorrect date is being loaded in date_api_elements.inc. With a single CCK field, this validation hook is being called three times. Two of the three times it passes without issues, and the fate format being displayed on #date_format is "m/d/Y"
the last one, which fails, is looking at the date format as...
"m/d/Y - g:ia"
At which point it fails.
To give a better idea of the date being entered, the example of how to enter the date is as shown...
09/23/2011 - 3:28pm
and the entered date is...
09/20/2011 - 12:00am
Need to fix the code to allow for this date to be updated, as the node is not updatable unless you set the field to blank, edit, and set the date value again.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | date_elements_7.x-2.x-dev-2011-Sep-08.patch | 1.69 KB | xrampage16 |
Comments
Comment #1
xrampage16 commentedI've gone ahead and created a patch, and also loaded the latest dev version of the module so that my patch could be applied to the latest dev version and fix the issue.
After a bit more work, and investigating, I discovered that the form api, when the node form is loaded, expects the data to formed in a particular manner, depending on the CCK field settings. In my instance, the field would be malformed if the data was not in the format "m/d/Y g:ia", and when the time was set to 12:00am, then the code inside of date_elements on line 470 converts 12:00am into an "all day" time format, and calls date_part_format until it finds a successful date pattern in "m/d/Y". But the issue is that that errors out, due to the form api requiring the CCK field to be in "m/d/Y g:ia". I wrote a quick fix which checks that all of the required values are submitted, and if so, performs a quick date->parse on the date object, and checks to see if there are errors. If there are errors, it will set the "all day" flag, and proceed. In the instance that I have run into, it will allow the values to pass through, as the date format is correct for what I am attempting to do.
The patch adds in this snippet of code. I have not testing it in all cases, but it allows my current situation to pass through without issues, and also allow for situations where an error does exist, to pass through to the original method, and be set as an all day event (as per the original coding method).
Comment #2
karens commentedA bug that happens only in a specific situation is not a critical bug that makes the module unusable. I need more information on how to reproduce the bug in a clean installation -- what type of date field, what type of widget, what are all the field and widget settings.
Comment #3
karens commentedNo response, closing.