In 5.x-1.8, I have defined a CCK Date field, with the following parameters:
Granularity: hour, minute
Custom date format: g:i A (which should show me hour:minute AM/PM)
Text box selector
Not multiple, not required
When I go to add content to this field, by clicking "Add Content" and choosing this CCK content type, the initial value for the time field is currently coming up as:
- 21:59
The negative sign is incorrect, and if I save the content without changing this to a valid time, I get an error message saying it's an invalid time.
My time zone is set to GMT (no offset) for this site -- time zone settings are all at their defaults.
I have also verified that the date() and gmdate() PHP functions work correctly on this server, and are not printing negative times.
I will investigate the date module and see if I can find where the problem is...
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | Patch to fix above problem in 1.x 5.x branch | 2.37 KB | jhodgdon |
Comments
Comment #1
jhodgdonI did a little investigation... It looks like the input formats are the problem.
In the date.inc file, there is this function called date_text_input that is setting up the field for the New Content data entry form.
The parameters passed into this function are incorrect -- specifically, the formats array looks like this (I used print_r( $params) to see it) -- note the hyphens or negative signs on those jscal and text formats:
[formats] => Array
(
[input] => Array
(
[site-wide] => m/d/Y - H:i
[jscal] => - %H:%M
[text] => - H:i
[select] => Array
(
)
[am_pm] =>
[desc] => MM/DD/YYYY - HH:MM
)
)
So I need to next figure out where those formats are coming from. My guess is that something is deciding that if I only have Hour and Minute components, it is taking the site-wide format (which has a - between the month/day/year and the hour/minute sections) and breaking it in half, but it needs to drop the - from its format!
Comment #2
jhodgdonOK, I see what the problem is. In function date_formats in date.inc in this module, there is an assumption that your granularity includes dates for sure, although times are optional. So near the end, it is building the formats from
( date format ) ( format separator ) ( time format )
If there is no time portion, it omits the format separator. However, it doesn't check to verify there is a date portion; it should also omit the format separator in that case.
I can probably make a patch... probably this is also a problem in the 2.x version of the module? Not sure, I haven't tested it.
Comment #3
jhodgdonI'm attaching a patch - hopefully I've gotten the format correct, this is the first time I've submitted a patch to a drupal project, so please tell me if I've done something wrong. :)
--Jennifer
Comment #4
jhodgdonIt also looks like the problem will still be there in the 2.x version that is being worked on, but I don't have an installation where I can easily test it right now, so someone might want to look into that...
Comment #5
dave the brave commentedI just had a similar problem in 1.8 where the default date (date field left empty) was being stored as zero, or zero - timezone offset, resulting in a date of 31 December 1969. I am using a date with granularity of 'day'.
To fix, I added a check for an empty field and defaulted the timestamp to now() in function date_gmgetdate, date.inc:
Was:
Now:
This doesn't take into account a situation where the date should not be displayed (i.e. should be '') if not entered, but there is obviously some issue with that code, and I don't require the date not to display.
- DB
Comment #6
karens commentedI'm not making changes to the 5.1 version. I'm officially recommending you move to the 5.2 version now. If you have problems in that version you can check for existing issues or add new ones. Feature requests are now getting posted to the D6 version to be back-ported to 5.2.
Comment #7
bgogoi commentedI am facing the same problem in version 6.2 http://drupal.org/node/491822
can someone pls help me fixing this? whr to find the error? there is no date.inc in the version 6.22