The empty field value was being updated in the Datestamp fields when these were submitted to the database.

Core settings:
Type - datestamp field (date field is working)
Widget - jscalendar (that is passing back an empty string '')
Timezone - Brisbane/Australia
Multiple option - No
Required option - No

I tracked the problem into the hook_field 'date_field', where the function 'date_unset_granularity' was converting the zero length string into an invalid date. I resolved the issue myself by setting the value to equal to NULL in the event of an empty string, otherwise, use the 'date_unset_granularity' function, as shown by the SVN patch below:

    Index: C:/Users/Alan/workspace/CaignWebs/sites/all/modules/date/date.module
===================================================================
--- C:/Users/Alan/workspace/CaignWebs/sites/all/modules/date/date.module  (revision 146)
+++ C:/Users/Alan/workspace/CaignWebs/sites/all/modules/date/date.module  (working copy)
@@ -116,8 +116,8 @@
       // so that won't work in the field, and doing it in the widget get much more complex, so leaving it here for now.
       foreach ($items as $delta => $item) {
         foreach ($process as $processed) {
-          if (!form_get_errors()) {
-            $replace = date_unset_granularity($item[$processed], date_granularity_array($field), $field['type']);
+          if (!form_get_errors()) {
+            $replace = ($item[$processed] != '') ? date_unset_granularity($item[$processed], date_granularity_array($field), $field['type']) : NULL;
             $items[$delta][$processed] = $replace !== 'ERROR' && $replace != $items[$delta][$processed] ? $replace : $items[$delta][$processed];
           }
         }

Regards

Alan

Comments

Leeteq’s picture

Status: Active » Needs review
cYu’s picture

I was having this same problem with Date(5.x-1.8) on a form with a Datestamp field and Select widget. When my form was submitted without changing any values on this field and then the created node was edited, Dec 31 1969 was displayed. -86400 was the timestamp stored in the database. Attempting to later edit the date proved problematic because the select box containing the year then held only (1969, 1970, and 1971).

After applying this patch I got the expected behavior with empty dates remaining empty until acted on.

ron_s’s picture

I applied this patch to the code, but I am finding that empty dates displayed in views are still be shown as January 1, 1970. This wasn't occurring in Date 5.x-1.7.

v1nce’s picture

Priority: Normal » Critical

Checking if the $timestamp is null in the date_format_date() function of date.inc should correct this issue.

if ($timestamp == NULL) {
    return;
}

Marking this as critical since it totally breaks the node form by setting the year value at 1969. If you have the default -3:+3 year setting this is a problem.

KarenS’s picture

Status: Needs review » Closed (won't fix)

I'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.

I don't think you'll see this problem in the 5.2 version.