Date Popup inserts wrong dates for empty dates

Upgrade to the latest -dev version of Date (and of Calendar, if you're using it). There have been lots of fixes since the rc version.

What kind of date did you create? What kind of widget are you using? What settings did you use? How can I reproduce your problem? Did you run update.php after you updated your code? Did you pull up your field and check that the settings are right after you updated your code?

This should be fixed by a commit I made earlier today.

This is really a different issue than the original one and it affects the -dev version. I am seeing sporatic problems with values in the Date Popup. Working on this now.

I think I got this problem ironed out now.

Just to adding that this is still an issue. 5.x-2.x-dev from 7/5/2008 and clean D5 install - saves 2008-01-01T00:00:00 on every date_popup field, single or multi.

Thanks for all your work on this, (great seeing you at drupalcon Boston!)

liveoutloud2day

Hi,

same problem here with the latest 5.x-2.x-dev release: whatever you enter in the date field, it becomes 01.01.2008. Configuration; Multi, Popup, granularity YYYY-MM-DD, formatting: DD.MM.YYYY. It does not matter, if the date is entered into the popup or directly into the date field. The entered date is also ignored when editing the date field after saving it once. No error or warning is recoded by the watchdog.

Greetings, -asb

same for me using latest from d6-dev (downloaded today)

By rolling back before June 24th, then adding in some of the things that changed since, I was able to get it to work. First just the first entry of a multi, then all. This patch works for me, but not sure why you removed it so it probably was breaking something else? In any case, give it a go and see if it fixes things.

liveoutloud2day

I'll take a look, that may be the problem.

@mrfelton, this is a 5.2 issue, something broken in 6.2 will be a completely different issue.

I am not able to replicate this problem in the very latest 5.2 dev code. I tested it in both PHP4 and PHP5 and get the right dates stored in every case. This is without the patch in #16, just using the current code.

I'm not sure if it's that people didn't have a version with all the latest fixes or if there's something about the problem that I'm not getting into my local installation. This was definitely happening earlier for me and is now fixed for me.

I'll leave it marked as 'needs more info' and we'll see if it comes up again as you pick up more current versions of the code.

Heh - I subscribed right as KarenS was providing further information, so I will edit to add more information.

In my case, I downloaded the latest Dev version today (7/7/08). I am using a Time type of field and I am entering the date using the jquery pop up. I do NOT enter the time, as it should automatically fill in 12:00am. It IS filling in 12:00am, but it is also changing my date to 1/1/2008.

@liveoutloud2day:

from where is the date_popup.module.01.01.2008.patch to be run? For me it's neither working from the drupal installation directory nor from /sites/all/modules/date, neither with or without -p0 option?

@KarenS:

Yes, for me this is still happening with the latest Date 5.x-2.x-dev from 2008-Jul-07.

Example: 22.08.2008 after saving becomes 01.01.2008

* Label: DVD-Start (BRD)
* Name: field_dvd_start_brd, weight: -6
* Widget: Text Field with jquery pop-up calendar
* Default value: Blank
* Required: no
* Format: 07.07.2008;
* Label: Inline;
* Teaser: Hidden;
* Full: Long;
* Date field is inside a field group with weight 4

Environment: Debian GNU/Linux, PHP 5.2.0-8+etch11, MySQL 5.0.32, Apache 2.2.3. If it helps, I can mail you a detailed output from phpinfo().

Thanks & greetings, -asb

Upon seeing asb's well-done example, I thought I should add my configuration to help pinpoint the problem:

The ONLY field added to my content type is the date field.
Type: date
Widget: Text Field with jquery pop-up calendar
Label: Date and Time
Default Value: Now
Input format: 07/08/2008 09:55:36
Date Settings: Required
Multiple: Unlimited
To Date: Optional
Granularity: Year, Month, Date, Hour, Minute
Time Zone Setting: Site's Time Zone

#21 - I have a date set up exactly this way and it works fine, in both PHP4 and PHP5. Try an export of your field (using Content Copy). Maybe there some setting that's still different. I assume you're in a test environment? If so, try disabling everything but the relevant modules, just in case something else is interfering.

Hi Karen,

[disabling everything but the relevant modules]

Sorry, due to another issue of the "date" module (managing dates before 1970) I'm running the module on several sites in a production environment. For such tests, I'd need to manually set up another site replica (takes some time, but I'll try).

For the export, I selected one content type ("film") and unselecte all groups and all fields except one ("field_dvd_start_brd"); I hope this helps:

$content[type]  = array (
  'name' => 'Film',
  'type' => 'film',
  'description' => 'Kino- oder Fernsehfilm.',
  'title_label' => 'Titel',
  'body_label' => 'Textkörper',
  'min_word_count' => '0',
  'help' => '',
  'node_options' => 
  array (
    'status' => true,
    'promote' => true,
    'sticky' => false,
    'revision' => false,
    'moderate' => false,
  ),
  'comment' => '2',
  'upload' => '1',
  'amazon_related_link' => '0',
  'comment_upload' => '1',
  'contactlink' => '1',
  'image_attach' => '1',
  'image_attach_size_teaser' => 'thumbnail',
  'image_attach_weight_teaser' => '-10',
  'image_attach_size_body' => 'preview',
  'image_attach_weight_body' => '-10',
  'upload_image_create' => '1',
  'upload_image_delete' => '1',
  'show_preview_changes' => 1,
  'nodewords' => 1,
  'old_type' => 'film',
  'orig_type' => '',
  'module' => 'node',
  'custom' => '1',
  'modified' => '1',
  'locked' => '0',
  'fivestar' => 1,
  'fivestar_stars' => '10',
  'fivestar_labels_enable' => 1,
  'fivestar_label_0' => 'Cancel rating',
  'fivestar_label_1' => 'Poor',
  'fivestar_label_2' => 'Okay',
  'fivestar_label_3' => 'Good',
  'fivestar_label_4' => 'Great',
  'fivestar_label_5' => 'Awesome',
  'fivestar_label_6' => 'Give it @star/@count',
  'fivestar_label_7' => 'Give it @star/@count',
  'fivestar_label_8' => 'Give it @star/@count',
  'fivestar_label_9' => 'Give it @star/@count',
  'fivestar_label_10' => 'Give it @star/@count',
  'fivestar_style' => 'dual',
  'fivestar_text' => 'dual',
  'fivestar_title' => 1,
  'fivestar_feedback' => 1,
  'fivestar_unvote' => 1,
  'fivestar_position_teaser' => 'hidden',
  'fivestar_position' => 'below',
  'fivestar_comment' => '0',
  'location_maxnum' => '0',
  'location_defaultnum' => '0',
  'location_weight' => '8',
  'location_collapsible' => 1,
  'location_collapsed' => 1,
  'location_rss' => 'w3c',
  'location_display_teaser' => 1,
  'location_display_full' => 1,
  'send_type' => 'film',
  'send_film_fulltext' => '',
  'send_film_linktext' => 'Per E-Mail versenden',
  'send_film_subject' => 'Nachricht aus CineDat',
  'send_film_message' => '',
  'send_film_template' => '%message
%body
',
  'send_film' => 1,
  'send_film_pernode' => '1',
  'taxonomy_context_inline' => '0',
  'taxonomy_context_breadcrumb' => '1',
  'xmlsitemap_node_type_priority' => '0.1',
  'xmlsitemap_old_priority' => '0.1',
);
$content[fields]  = array (
  0 => 
  array (
    'widget_type' => 'date_popup',
    'label' => 'DVD-Start (BRD)',
    'weight' => '-6',
    'default_value' => 'blank',
    'default_value_code' => '',
    'default_value2' => 'blank',
    'default_value_code2' => '',
    'input_format' => 'd.m.Y H:i:s',
    'input_format_custom' => '',
    'year_range' => '-10:+1',
    'increment' => '1',
    'advanced' => 
    array (
      'label_position' => 'above',
      'text_parts' => 
      array (
        'year' => 0,
        'month' => 0,
        'day' => 0,
        'hour' => 0,
        'minute' => 0,
        'second' => 0,
      ),
    ),
    'description' => '',
    'group' => 'group_starttermine',
    'required' => '0',
    'multiple' => '0',
    'repeat' => 0,
    'todate' => '',
    'granularity' => 
    array (
      'year' => 'year',
      'month' => 'month',
      'day' => 'day',
    ),
    'output_format_date' => 'l, j. F Y - G:i',
    'output_format_custom' => '',
    'output_format_date_long' => 'l, j. F Y - G:i',
    'output_format_custom_long' => '',
    'output_format_date_medium' => 'j. F Y - G:i',
    'output_format_custom_medium' => '',
    'output_format_date_short' => 'd.m.Y - H:i',
    'output_format_custom_short' => '',
    'tz_handling' => 'none',
    'timezone_db' => 'UTC',
    'field_name' => 'field_dvd_start_brd',
    'field_type' => 'date',
    'module' => 'date',
    'label_position' => 'above',
    'text_parts' => 
    array (
    ),
    'display_settings' => 
    array (
      'label' => 
      array (
        'format' => 'inline',
      ),
      'teaser' => 
      array (
        'format' => 'hidden',
      ),
      'full' => 
      array (
        'format' => 'long',
      ),
    ),
  ),
);

Just for the record: I'm running date 5.x-2.x-dev on five sites with different code base, and the issue occurs on all sites. Common to all sites is the hosting, the dedicated server (AMD Opteron, hopefully not a hardware issue ;) and a set of contributed modules. All sites are localized to German, were installed with D4.x or D5.x and upgraded from date 1.x. As instructed, I'm currently running update.php on a quite regular basis (several modules from contrib are updated per week, the "date" module even more frequent at the moment ;).

I'm sorry for not being able to provide a patch!

Thanks & greetings, -asb

Whew! You have a ton of other modules interacting with this field -- Fivestar, location, image_attach, upload_image, send_film (what's that one?).

I'll try just the date field, and if I don't see problems on my installation I'll introduce some of these other modules to see if that affects anything.

BTW, don't use this patch because it probably will break other things, I just need to nail down why your setup seems to need that patch.

No luck on re-creating the date field. There were several differences in your date from what I was testing -- granularity, timezone option -- but even when I exactly mimic your setup it works absolutely fine for me.

BrianJubal - do you have any of the same extra modules installed as asb does? If not, I don't need to go through and install them since they're probably not the source of the problem.

One small thing I found is that you are missing a value in your export which is a new setting I recently added, which indicates either you don't have the latest code or you haven't re-saved your field settings recently. Try editing your field settings and save it (even if you don't change anything) just to see if it makes any difference.

@asb: That patch was from the root directory of the date modules. I have included another patch to be run from the date_popup directory.

@KarenS: I have just once again replicated the problem - date saves as 01/01/2008 - this is a fresh D5.7 install with admin_menu being the only other module beside date (date,date_api,date_timezone, date_popup) and cck (content, content_copy). I have included the updated patch that works for me. Any idea of what this patch might break?

BTW: tested this against the dev version of CCK (I am using cck-5.x-1.7) and it still acts the same way, no go before patch, works great afterward.

Here is my cck type if you want to test:

$content[type] = array (
'name' => 'A Test',
'type' => 'a_test',
'description' => '',
'title_label' => 'Title',
'body_label' => 'Body',
'min_word_count' => '0',
'help' => '',
'node_options' =>
array (
'status' => true,
'promote' => true,
'sticky' => false,
'revision' => false,
),
'comment' => '2',
'old_type' => 'a_test',
'orig_type' => '',
'module' => 'node',
'custom' => '1',
'modified' => '1',
'locked' => '0',
);
$content[fields] = array (
0 =>
array (
'widget_type' => 'date_popup',
'label' => 'date',
'weight' => '0',
'default_value' => 'blank',
'default_value_code' => '',
'default_value2' => 'same',
'default_value_code2' => '',
'input_format' => 'd/m/Y H:i:s',
'input_format_custom' => '',
'year_range' => '-3:+3',
'increment' => '1',
'advanced' =>
array (
'label_position' => 'above',
'text_parts' =>
array (
'year' => 0,
'month' => 0,
'day' => 0,
'hour' => 0,
'minute' => 0,
'second' => 0,
),
),
'description' => '',
'required' => '1',
'multiple' => '1',
'repeat' => 0,
'todate' => '',
'granularity' =>
array (
'year' => 'year',
'month' => 'month',
'day' => 'day',
),
'output_format_date' => 'm/d/Y - H:i',
'output_format_custom' => '',
'output_format_date_long' => 'l, F j, Y - H:i',
'output_format_custom_long' => '',
'output_format_date_medium' => 'D, m/d/Y - H:i',
'output_format_custom_medium' => '',
'output_format_date_short' => 'm/d/Y - H:i',
'output_format_custom_short' => '',
'tz_handling' => 'none',
'timezone_db' => 'UTC',
'field_name' => 'field_date',
'field_type' => 'date',
'module' => 'date',
'label_position' => 'above',
'text_parts' =>
array (
),
),
);

Your export is also missing the new date setting, so I'm still wondering if we're all using the same code. I guess I'll substitute the tarball for the code I'm using now and see what happens.

Hi, KarenS! Sorry it took me a while to get to you... my content type doesn't interact with much at all. Here's the export:

$content[type]  = array (
  'name' => 'Calendar Date',
  'type' => 'caldate',
  'description' => 'The is a date meant for the calendar.',
  'title_label' => 'Title',
  'body_label' => '',
  'min_word_count' => '0',
  'help' => '',
  'node_options' => 
  array (
    'status' => true,
    'promote' => false,
    'sticky' => false,
    'revision' => false,
  ),
  'upload' => '1',
  'image_attach' => '0',
  'image_attach_size_teaser' => 'thumbnail',
  'image_attach_weight_teaser' => '0',
  'image_attach_size_body' => 'thumbnail',
  'image_attach_weight_body' => '0',
  'webfm_attach' => '0',
  'old_type' => 'caldate',
  'orig_type' => '',
  'module' => 'node',
  'custom' => '1',
  'modified' => '1',
  'locked' => '0',
  'xmlsitemap_node_type_priority' => '0.2',
  'xmlsitemap_old_priority' => '0.2',
);
$content[fields]  = array (
  0 => 
  array (
    'widget_type' => 'date_popup',
    'label' => 'Date and Time',
    'weight' => '0',
    'default_value' => 'now',
    'default_value_code' => '',
    'default_value2' => 'blank',
    'default_value_code2' => '',
    'input_format' => 'm/d/Y h:i:sA',
    'input_format_custom' => '',
    'year_range' => '-3:+3',
    'increment' => '1',
    'advanced' => 
    array (
      'label_position' => 'above',
      'text_parts' => 
      array (
        'year' => 0,
        'month' => 0,
        'day' => 0,
        'hour' => 0,
        'minute' => 0,
        'second' => 0,
      ),
    ),
    'description' => '',
    'group' => false,
    'required' => '1',
    'multiple' => '1',
    'repeat' => 0,
    'todate' => 'optional',
    'granularity' => 
    array (
      'year' => 'year',
      'month' => 'month',
      'day' => 'day',
      'hour' => 'hour',
      'minute' => 'minute',
    ),
    'output_format_date' => 'm/d/Y - g:ia e',
    'output_format_custom' => '',
    'output_format_date_long' => 'l, F j, Y - g:ia',
    'output_format_custom_long' => '',
    'output_format_date_medium' => 'D, m/d/Y - g:ia',
    'output_format_custom_medium' => '',
    'output_format_date_short' => 'm/d/Y - g:ia',
    'output_format_custom_short' => '',
    'tz_handling' => 'site',
    'timezone_db' => 'UTC',
    'field_name' => 'field_datecal',
    'field_type' => 'date',
    'module' => 'date',
    'label_position' => 'above',
    'text_parts' => 
    array (
    ),
  ),
);

I finally got this replicated and fixed, using an example provided in http://drupal.org/node/280899, which turned out to be the perfect example for fixing this because it had one field that had the original problem I was trying to fix and one that got broken by the fix. I fixed the fix and it broke the first date again, but then I found a way to fix both. Hopefully all is well now :)

Just updated to the latest Dev version. Now time is REQUIRED before anyone can move on (it doesn't fill in 12:00 am automatically for you, you have to manually enter it). If that was the intention, then I agree, this problem is fixed, and our users will just have to get used to entering a time. :) Thanks Karen!

#31, not sure I know what you mean. You mean you have a date that is not required but it forces you to input a time anyway?

Hi Karen,

I can confirm that the latest 5.x-2-x-dev release from July 13th has this fixed for me. Very nice work!

WARNING to drush users: Since RC2 is the recommended release for the "date" module, it will downgrade 5.x-2-x-dev to 5.x-2-x-rc2 ;-)

Thanks again, Karen, & greetings, -asb

Karen,

In my installation I require the from date with an optional to date. In previous versions I was able to put in the from date, and the time was automatically filled in as 12:00am if I left the time blank. This is no longer the case. The problem I was having was when the to date TIME field was left blank, it would fill in 12:00am (like it used to) but it would also reset the to date DATE back to 01/01/08. Now when the to date TIME field is left blank, it gives an error message that you cannot leave the time field blank. I hope that clarifies what was happening, what my issue was, and how the latest dev version has resolved the issue.

I would say the current behavior is 'by design'. There are lots of ways to interpret that missing value and I'm not sure it was ever right to assume it is 12am (if I create a date that has hours and minutes I might *want* users to fill something in so I know they didn't miss the field). The current logic is if you leave a date field completely empty, there is no error, but if you incorrectly or incompletely fill it out, there is an error because we don't know for sure what you intended for the missing parts. You could make a case that it would make more sense to make the assumption that it is an all day date or provide some options about what should happen with that.

We currently have a feature request about creating an 'all day' checkbox for the date that could be used instead of the time and there is a feature request about allowing 'fuzzy granularity' to let users leave date parts empty if they want, so one of those could be a solution, or you might want to create a different feature request with specifics about how we would structure this.

But that's all getting away from the original bug report, so I'm marking this fixed.