After module upgrade, Views filter value "now" incorrectly outputs 2009-01-01

Same problem here, subscribing.

same for me, subscribing.

Drupal 6.10
Date: 6.x-2.0
Views: 6.x-2.3
PHP: 5.2.5
MySQL: 5.0.24

Same problem here. My setup:

Drupal: 6.10
Date: 6.x-2.0
PHP 5.2.8
MySQL database 5.0.67

same problem here

i just put in todys date by hand and it is also changed to 2009-01-01

Some of the filter settings have changed and there is a chance you have old values stuck in a cache somewhere. Delete your filter, save the view with no filter on it (to be sure the all cached values get cleared out), then add the filter back in.

I duplicated my view, deleted the filter, saved the view with no filter on it, added the filter back in but the problem persists.
I also flushed all caches a couple of times.

I need to see an export of a view that behaves this way so I can see how the filter is set up. And I need to know what kind of date field you are using (date, datestamp, or datetime) and how it is set up. You can show me this with an export of the date field (use Content Copy to export that).

first of all, thank you for the fast replies.

the field i'm using for the filter is set up as date

here is the export of the content type

$content[type]  = array (
  'name' => 'Aktion',
  'type' => 'aktion',
  'description' => 'Standard-Vorlage für Aktionen',
  'title_label' => 'Name der Aktion',
  'body_label' => 'Textkörper',
  'min_word_count' => '0',
  'help' => '',
  'node_options' => 
  array (
    'status' => true,
    'promote' => true,
    'sticky' => false,
    'revision' => false,
  ),
  'language_content_type' => '0',
  'upload' => '1',
  'old_type' => 'aktion',
  'orig_type' => '',
  'module' => 'node',
  'custom' => '1',
  'modified' => '1',
  'locked' => '0',
  'comment' => '0',
  'comment_default_mode' => '4',
  'comment_default_order' => '2',
  'comment_default_per_page' => '50',
  'comment_controls' => '3',
  'comment_anonymous' => '0',
  'comment_subject_field' => '1',
  'comment_preview' => '1',
  'comment_form_location' => '0',
  'image_attach' => '0',
  'image_attach_size_teaser' => 'thumbnail',
  'image_attach_weight_teaser' => '0',
  'image_attach_size_body' => 'thumbnail',
  'image_attach_weight_body' => '0',
);
$content[groups]  = array (
  0 => 
  array (
    'label' => 'Alle Infos',
    'group_type' => 'standard',
    'settings' => 
    array (
      'form' => 
      array (
        'style' => 'fieldset',
        'description' => '',
      ),
      'display' => 
      array (
        'description' => '',
        'teaser' => 
        array (
          'format' => 'fieldset',
          'exclude' => 0,
        ),
        'full' => 
        array (
          'format' => 'fieldset',
          'exclude' => 0,
        ),
        4 => 
        array (
          'format' => 'fieldset',
          'exclude' => 0,
        ),
        2 => 
        array (
          'format' => 'fieldset',
          'exclude' => 0,
        ),
        3 => 
        array (
          'format' => 'fieldset',
          'exclude' => 0,
        ),
        'token' => 
        array (
          'format' => 'fieldset',
          'exclude' => 0,
        ),
        'label' => 'above',
      ),
    ),
    'weight' => '-2',
    'group_name' => 'group_organisation',
  ),
);
$content[fields]  = array (
  0 => 
  array (
    'label' => 'Ort',
    'field_name' => 'field_ort',
    'type' => 'text',
    'widget_type' => 'text_textfield',
    'change' => 'Basisinformation ändern',
    'weight' => '6',
    'rows' => 5,
    'size' => '60',
    'description' => '',
    'default_value' => 
    array (
      0 => 
      array (
        'value' => 'wird noch bekanntgegeben',
        '_error_element' => 'default_value_widget][field_ort][0][value',
      ),
    ),
    'default_value_php' => '',
    'default_value_widget' => NULL,
    'group' => 'group_organisation',
    'required' => 0,
    'multiple' => '0',
    'text_processing' => '0',
    'max_length' => '',
    'allowed_values' => '',
    'allowed_values_php' => '',
    'op' => 'Feldeinstellungen speichern',
    'module' => 'text',
    'widget_module' => 'text',
    'columns' => 
    array (
      'value' => 
      array (
        'type' => 'text',
        'size' => 'big',
        'not null' => false,
        'sortable' => true,
      ),
    ),
    'display_settings' => 
    array (
      'weight' => '6',
      'parent' => 'group_organisation',
      'label' => 
      array (
        'format' => 'inline',
      ),
      'teaser' => 
      array (
        'format' => 'default',
        'exclude' => 0,
      ),
      'full' => 
      array (
        'format' => 'default',
        'exclude' => 0,
      ),
      4 => 
      array (
        'format' => 'default',
        'exclude' => 0,
      ),
      2 => 
      array (
        'format' => 'default',
        'exclude' => 0,
      ),
      3 => 
      array (
        'format' => 'default',
        'exclude' => 0,
      ),
    ),
  ),
  1 => 
  array (
    'label' => 'von',
    'field_name' => 'field_aktion_startdatum',
    'type' => 'date',
    'widget_type' => 'date_text',
    'change' => 'Basisinformation ändern',
    'weight' => '7',
    'default_value' => 'strtotime',
    'default_value2' => 'same',
    'default_value_code' => '+12 Friday',
    'default_value_code2' => '',
    'input_format' => 'Y-m-d H:i:s',
    'input_format_custom' => 'Y-m-d',
    'advanced' => 
    array (
      'label_position' => 'above',
      'text_parts' => 
      array (
        'year' => 0,
        'month' => 0,
        'day' => 0,
        'hour' => 0,
        'minute' => 0,
        'second' => 0,
      ),
    ),
    'increment' => 1,
    'year_range' => '-3:+3',
    'label_position' => 'above',
    'text_parts' => 
    array (
    ),
    'description' => 'Bitte das Startdatum im Format JJJJ-MM-TT eingeben.',
    'group' => 'group_organisation',
    'required' => 1,
    'multiple' => '0',
    'repeat' => 0,
    'todate' => '',
    'granularity' => 
    array (
      'year' => 'year',
      'month' => 'month',
      'day' => 'day',
    ),
    'default_format' => 'field_aktion_startdatum_default',
    'tz_handling' => 'none',
    'timezone_db' => 'Europe/Berlin',
    'op' => 'Feldeinstellungen speichern',
    'module' => 'date',
    'widget_module' => 'date',
    'columns' => 
    array (
      'value' => 
      array (
        'type' => 'varchar',
        'length' => 20,
        'not null' => false,
        'sortable' => true,
        'views' => true,
      ),
    ),
    'display_settings' => 
    array (
      'weight' => '7',
      'parent' => 'group_organisation',
      'label' => 
      array (
        'format' => 'inline',
      ),
      'teaser' => 
      array (
        'format' => 'field_aktion_startdatum_default',
        'exclude' => 0,
      ),
      'full' => 
      array (
        'format' => 'field_aktion_startdatum_default',
        'exclude' => 0,
      ),
      4 => 
      array (
        'format' => 'field_aktion_startdatum_default',
        'exclude' => 0,
      ),
      2 => 
      array (
        'format' => 'field_aktion_startdatum_default',
        'exclude' => 0,
      ),
      3 => 
      array (
        'format' => 'field_aktion_startdatum_default',
        'exclude' => 0,
      ),
    ),
  ),
  2 => 
  array (
    'label' => 'bis',
    'field_name' => 'field_aktion_enddatum',
    'type' => 'date',
    'widget_type' => 'date_text',
    'change' => 'Basisinformation ändern',
    'weight' => '8',
    'default_value' => 'strtotime',
    'default_value2' => 'same',
    'default_value_code' => '+12 Sunday',
    'default_value_code2' => '',
    'input_format' => 'Y-m-d H:i:s',
    'input_format_custom' => 'Y-m-d',
    'advanced' => 
    array (
      'label_position' => 'above',
      'text_parts' => 
      array (
        'year' => 0,
        'month' => 0,
        'day' => 0,
        'hour' => 0,
        'minute' => 0,
        'second' => 0,
      ),
    ),
    'increment' => 1,
    'year_range' => '-3:+3',
    'label_position' => 'above',
    'text_parts' => 
    array (
    ),
    'description' => 'Bitte das Enddatum im Format JJJJ-MM-TT eingeben.',
    'group' => 'group_organisation',
    'required' => 1,
    'multiple' => '0',
    'repeat' => 0,
    'todate' => '',
    'granularity' => 
    array (
      'year' => 'year',
      'month' => 'month',
      'day' => 'day',
    ),
    'default_format' => 'field_aktion_enddatum_default',
    'tz_handling' => 'none',
    'timezone_db' => 'Europe/Berlin',
    'op' => 'Feldeinstellungen speichern',
    'module' => 'date',
    'widget_module' => 'date',
    'columns' => 
    array (
      'value' => 
      array (
        'type' => 'varchar',
        'length' => 20,
        'not null' => false,
        'sortable' => true,
        'views' => true,
      ),
    ),
    'display_settings' => 
    array (
      'weight' => '8',
      'parent' => 'group_organisation',
      'label' => 
      array (
        'format' => 'inline',
      ),
      'teaser' => 
      array (
        'format' => 'field_aktion_enddatum_default',
        'exclude' => 0,
      ),
      'full' => 
      array (
        'format' => 'field_aktion_enddatum_default',
        'exclude' => 0,
      ),
      4 => 
      array (
        'format' => 'field_aktion_enddatum_default',
        'exclude' => 0,
      ),
      2 => 
      array (
        'format' => 'field_aktion_enddatum_default',
        'exclude' => 0,
      ),
      3 => 
      array (
        'format' => 'field_aktion_enddatum_default',
        'exclude' => 0,
      ),
    ),
  ),
  3 => 
  array (
    'label' => 'Kosten',
    'field_name' => 'field_teilnahmebeitrag',
    'type' => 'text',
    'widget_type' => 'text_textfield',
    'change' => 'Basisinformation ändern',
    'weight' => '9',
    'rows' => 5,
    'size' => '60',
    'description' => '',
    'default_value' => 
    array (
      0 => 
      array (
        'value' => '100 € (inkl. Fahrtkostenerstattung bei Nutzung der günstigsten Anreisemöglichkeit)',
        '_error_element' => 'default_value_widget][field_teilnahmebeitrag][0][value',
      ),
    ),
    'default_value_php' => '',
    'default_value_widget' => 
    array (
      'field_teilnahmebeitrag' => 
      array (
        0 => 
        array (
          'value' => '100 € (inkl. Fahrtkostenerstattung bei Nutzung der günstigsten Anreisemöglichkeit)',
          '_error_element' => 'default_value_widget][field_teilnahmebeitrag][0][value',
        ),
      ),
    ),
    'group' => 'group_organisation',
    'required' => 0,
    'multiple' => '0',
    'text_processing' => '0',
    'max_length' => '',
    'allowed_values' => '',
    'allowed_values_php' => '',
    'op' => 'Feldeinstellungen speichern',
    'module' => 'text',
    'widget_module' => 'text',
    'columns' => 
    array (
      'value' => 
      array (
        'type' => 'text',
        'size' => 'big',
        'not null' => false,
        'sortable' => true,
      ),
    ),
    'display_settings' => 
    array (
      'weight' => '9',
      'parent' => 'group_organisation',
      'label' => 
      array (
        'format' => 'inline',
      ),
      'teaser' => 
      array (
        'format' => 'default',
        'exclude' => 0,
      ),
      'full' => 
      array (
        'format' => 'default',
        'exclude' => 0,
      ),
      4 => 
      array (
        'format' => 'default',
        'exclude' => 0,
      ),
      2 => 
      array (
        'format' => 'default',
        'exclude' => 0,
      ),
      3 => 
      array (
        'format' => 'default',
        'exclude' => 0,
      ),
    ),
  ),
);
$content[extra]  = array (
  'title' => '-5',
  'body_field' => '-3',
  'menu' => '-4',
  'attachments' => '-1',
);

and here is my view:

$view = new view;
$view->name = 'aktionen_archiv_baustelle';
$view->description = 'Zeigt eine Uebersicht über vergangene Aktionen als Tabelle an';
$view->tag = '';
$view->view_php = '';
$view->base_table = 'node';
$view->is_cacheable = FALSE;
$view->api_version = 2;
$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */
$handler = $view->new_display('default', 'Standards', 'default');
$handler->override_option('fields', array(
  'title' => array(
    'label' => 'Aktion',
    'link_to_node' => 1,
    'exclude' => 0,
    'id' => 'title',
    'table' => 'node',
    'field' => 'title',
    'relationship' => 'none',
  ),
  'field_aktion_startdatum_value' => array(
    'label' => 'von',
    'link_to_node' => 0,
    'label_type' => 'widget',
    'format' => 'default',
    'multiple' => array(
      'group' => TRUE,
      'multiple_number' => '',
      'multiple_from' => '',
      'multiple_reversed' => FALSE,
    ),
    'exclude' => 0,
    'id' => 'field_aktion_startdatum_value',
    'table' => 'node_data_field_aktion_startdatum',
    'field' => 'field_aktion_startdatum_value',
    'relationship' => 'none',
  ),
  'field_aktion_enddatum_value' => array(
    'label' => 'bis',
    'link_to_node' => 0,
    'label_type' => 'widget',
    'format' => 'default',
    'multiple' => array(
      'group' => TRUE,
      'multiple_number' => '',
      'multiple_from' => '',
      'multiple_reversed' => FALSE,
    ),
    'exclude' => 0,
    'id' => 'field_aktion_enddatum_value',
    'table' => 'node_data_field_aktion_enddatum',
    'field' => 'field_aktion_enddatum_value',
    'relationship' => 'none',
  ),
));
$handler->override_option('sorts', array(
  'field_aktion_startdatum_value' => array(
    'order' => 'ASC',
    'delta' => -1,
    'id' => 'field_aktion_startdatum_value',
    'table' => 'node_data_field_aktion_startdatum',
    'field' => 'field_aktion_startdatum_value',
    'relationship' => 'none',
  ),
));
$handler->override_option('arguments', array(
  'date_argument' => array(
    'default_action' => 'not found',
    'style_plugin' => 'default_summary',
    'style_options' => array(),
    'wildcard' => 'all',
    'wildcard_substitution' => 'Alle',
    'title' => '',
    'default_argument_type' => 'fixed',
    'default_argument' => '',
    'validate_type' => 'none',
    'validate_fail' => 'not found',
    'date_fields' => array(
      'node_data_field_aktion_enddatum.field_aktion_enddatum_value' => 'node_data_field_aktion_enddatum.field_aktion_enddatum_value',
    ),
    'year_range' => '-25:+5',
    'date_method' => 'AND',
    'granularity' => 'month',
    'id' => 'date_argument',
    'table' => 'node',
    'field' => 'date_argument',
    'relationship' => 'none',
    'default_options_div_prefix' => '',
    'default_argument_user' => 0,
    'default_argument_fixed' => '',
    'default_argument_php' => '',
    'validate_argument_node_type' => array(
      'image' => 0,
      'poll' => 0,
      'forum' => 0,
      'aktion' => 0,
      'seite' => 0,
      'story' => 0,
    ),
    'validate_argument_node_access' => 0,
    'validate_argument_nid_type' => 'nid',
    'validate_argument_vocabulary' => array(
      '1' => 0,
      '2' => 0,
    ),
    'validate_argument_type' => 'tid',
    'validate_argument_php' => '',
  ),
));
$handler->override_option('filters', array(
  'type' => array(
    'operator' => 'in',
    'value' => array(
      'aktion' => 'aktion',
    ),
    'group' => '0',
    'exposed' => FALSE,
    'expose' => array(
      'operator' => FALSE,
      'label' => '',
    ),
    'id' => 'type',
    'table' => 'node',
    'field' => 'type',
    'relationship' => 'none',
  ),
  'status_extra' => array(
    'operator' => '=',
    'value' => '',
    'group' => '0',
    'exposed' => FALSE,
    'expose' => array(
      'operator' => FALSE,
      'label' => '',
    ),
    'id' => 'status_extra',
    'table' => 'node',
    'field' => 'status_extra',
    'relationship' => 'none',
  ),
  'date_filter' => array(
    'operator' => '<',
    'value' => array(
      'value' => NULL,
      'min' => NULL,
      'max' => NULL,
      'default_date' => 'now',
      'default_to_date' => '',
    ),
    'group' => '0',
    'exposed' => FALSE,
    'expose' => array(
      'operator' => FALSE,
      'label' => '',
    ),
    'date_fields' => array(
      'node_data_field_aktion_enddatum.field_aktion_enddatum_value' => 'node_data_field_aktion_enddatum.field_aktion_enddatum_value',
    ),
    'date_method' => 'OR',
    'granularity' => 'day',
    'form_type' => 'date_select',
    'default_date' => 'now',
    'default_to_date' => '',
    'year_range' => '-3:+3',
    'id' => 'date_filter',
    'table' => 'node',
    'field' => 'date_filter',
    'relationship' => 'none',
  ),
));
$handler->override_option('access', array(
  'type' => 'none',
));
$handler->override_option('empty', 'Im ausgewählten Jahr sind (noch) keine Aktionen gelaufen!');
$handler->override_option('empty_format', '1');
$handler->override_option('style_plugin', 'table');
$handler->override_option('style_options', array(
  'grouping' => '',
  'override' => 1,
  'sticky' => 0,
  'order' => 'asc',
  'columns' => array(
    'title' => 'title',
    'field_aktion_startdatum_value' => 'field_aktion_startdatum_value',
    'field_aktion_enddatum_value' => 'field_aktion_enddatum_value',
  ),
  'info' => array(
    'title' => array(
      'sortable' => 0,
      'separator' => '',
    ),
    'field_aktion_startdatum_value' => array(
      'sortable' => 0,
      'separator' => '',
    ),
    'field_aktion_enddatum_value' => array(
      'sortable' => 0,
      'separator' => '',
    ),
  ),
  'default' => '-1',
));

i use the field_aktion_enddatum for filtering

Same problem here, subscribing.

Try using today instead of now and see if that fixes the problem. Yesterday I tried to figure out how to put in default values for the date filter on a view. I could not do it numerically for month year, even though I tried 2007-01 and 2007-01-01. But I found that I could use the selector on the view setup page and put today in for the "to" date.

i tried using now, today, tomorrow, yesterday, 2009-02-28
but they were all changed to 2009-01-01 for the query

Same problem for me, subscribing.

subscribing -

"now + 1 day" behaves the same way... 2009-01-01

I just changed to exposed filter and then the filtering works. Changing back to unexposed and the filtering doesn't work.

I just committed a fix to -dev. The problem would only affect non-exposed filters that needed a default value computed. If you use the tarball, you won't see it until the tarball is updated. If you use cvs it should be there now.

Thanks for the examples of a view and a field, that helped a lot.

Thank you for the fix, works for me! (I just learned how to check out modules from CVS: http://drupal.org/handbook/cvs)

Will there be a 6.x-2.0.1 or a 6.x-2.1 version soon?

There are always a few bugs in a new release. I'm going to wait and see if there are any other big ones reported right away before creating a new version.

Hello Karen:

I'm think that one big bug that should be solved in the next realease is the related to custom format:

I have founded two issues related to this bug:

#363820: Escaped/Unrecognized Characters entered into custom default display format get shown for "to date" even if one does not exist.
#375864: Formatting issue

I think that this issue is critical for sites with custom date formats, like Latin American sites.

Sorry for my english
Mariano

subscribing

Makes "now" work fine. Thanks for the quick response.

Helllo,

i have the same problem is it possible to get a patch or something for this?

Thanks

strauch

same problem here, subscribe

Same problem, subscribing

same problem - subscribing

I've the same problem. If I use 'now' the query filters with 2009-01-01 instead of the current date.
If I use an specific date works fine.

any suggestion?

any HowTo to explain what to do?

thx

Drupal: 6.10
Date: 6.x-2.0
Calendar: 6.x.2.0
PHP: 5.2.8
MySQL database: 5.0.67-community

KarenS says:

I just committed a fix to -dev

Then, please try date-2.x-dev.

Thx, now it works properly.

:)

sorry but isn't it a little bit crazy to use a dev version on a live site because the release doesn't work? i would prefer a patch. But maybe there is no other way?

This dev version only includes a few bug fixes. You can see the differences in the cvs messages.

If you prefer a patch, you always can create one making a diff from the cvs Here click on patch.

But I recomend use the dev version, until 2.1 version be released. Because as KarenS said, this version only includes a few bug fixes.

ok thanks, i will use the dev version. Thanks for the explanation about the patch from cvs page.

Agree!

Guys! Please don't do a releases until test all.

A big huge live site with many views has been broken after update!

PLEASE NEXT TIME TEST IT, TEST IT, TEST IT.

Better to have a dev version for a years, then buggy release versions.

Thanks.

Dmitry

PLEASE NEXT TIME TEST IT, TEST IT, TEST IT.

So if there is a bug you assume I committed this without doing any testing? There was no reason for this comment.

I agree, no reason whatsoever for that comment. We have all experienced some frustration with this issue, and KarenS has been responding and updating code in a very timely fashion. I think we all should be saying Thank You. After all, this is OSS. Maybe YOU should have installed the update on a test site, before just going for it in production. Give me a break.

thanks for the quick update!

subscribing

No reason????

Why I am getting now (All Day) text at the end of half my CCK date fields?

Guys I have more than 20 date fields in different content types - it's very big problem for me. It's not a games.

Looks like a recent updates 2.0 and next dev - completely different from previous. There is a huge gap with it - I don't think you should release it as new update when you build new tables and move formats to it - as release without testing on dev version.

Tell me guys better - how to remove that stupid (All Day) - who ever need that text at all? It's just a datetime field in CCK. It's not period From-Till.

Thanks.

D

benjf, this was a bug in RELEASE version!!!!! No problems if it's in dev - but kerenS released a new version without testing it on dev versions. That even was not a 1.91 version and not 1.999version. And not RC, and not Alpha or Beta. IT WAS A FIXED NUMBER 2.0 VERSION!!!

Okay guys for people who have a similar issue with (All Day) text.

At the file: date/date.theme
Comment line 300 and add next line like this:


//return trim(date_format_date($$which, 'custom', $format) .' '. theme('date_all_day_label'));
return trim(date_format_date($$which, 'custom', $format));


It will make that stupid text go away for ever (until next buggy update :-))!

Good luck guys!

PS. For module developers - issue appeared after very buggy automatic date format conversion upon a 2.0 version update. I dunno why but a some datetime CCK fields appear with (All day) text at the end. FIX IT PLEASE. And don't release a new FIXED NUMBER version until all tested in dev. Thanks.

Dmitry

KarenS, thanks for the fix. I'm subscribing so I can be notified of the official update, which I'd rather use than a dev or nightly release.
this is a fairly major bug, so hopefully another official release is issued soon!

A small note to webstylemedia, you should be a little more considerate to the hard working module developers on drupal.org. I don't see you making any contributions to the community aside from activity in 19 topics/issues (some being advertisements for your websites). If you have issues with a bad commit, then consider helping out instead of simply typing in all caps, using multiple exclamation points, and being generally negative to those who are the heart and soul of drupal.

Subscribing. I have a subdomain I created to test updates before committing them to the live site, and I saw this behavior there, so I haven't put it on my production site. All users have that choice of testing changes on their own.

I'm grateful to KarenS for updating this module. It's volunteers like KarenS that make this site and others like this possible.

Ron Williams, I can contribute! And I tried! I even updated some modules (several "too busy developers" did not had a time to update from D5 to D6) and offered to post it here. But moderators here didn't provided me a CVS access due a rules that I can't update a modules of other people.

Please understand me right, I like Drupal and community and I understand that community trying to keep all very well controlled and doesn't allow different versions of the same modules, doesn't allow garbage, not well-formatted code or other things and that is okay and I appreciate that.

I really dunno how correctly write a patches (how to make it in correct format) so Drupal accept it. I don't really understand how get an access to CVS. And I found it's really hard to even post a case study! Too many rules for all of this!!!! That's why I don't contribute. But I appreciate that you keep Drupal secured from possible non-professional coders etc. I don't have any questions to drupal moderators on this and I accept this. (Maybe just it will be good if they can post a better guidelines for these questions - patches, CVS, case studies).

All I want is just keeping the same high standards in all your FIXED NUMBER releases.

Thanks.

D

PS. Ron if you or others have any questions - they may ask me - I will like to help. I am in biz for more than 10 years. Manage 2 web development and internet advertising companies. Started from coder. Have a great experience in Drupal and can answer almost any question. Just ask me. I can't sit in forums - because I have other job. Maybe if you can invite me in official contributors list I can offer more time and help to others in forums and groups.

@Dmitry:

Okay guys for people who have a similar issue with (All Day) text.

At the file: date/date.theme
Comment line 300 and add next line like this:

This is a different issue, but for the record, a better approach is just to write a new theme function for the 'All day' label:

theme_date_all_day_label() {
  return '<span></span>';
}

You could also return just an empty string, but be warned that that doesn't work if you're only showing the time, since then the whole date/time string is empty and something later on replaces it by '12:00 AM'.

Hi,

Maybe it could be a good idea to post a warning about this bug in the download page?

Hi again,

I've read this:

>I just changed to exposed filter and then the filtering works. Changing back to unexposed and the filtering doesn't work.

but after I installed the dev version it happens the contrary, I have to change it to unexposed to make it work. If it only works in this mode, should not be a warning in the download page, ot at least in the release notes, and also about the bug in general?

Thanks

Upgrading to dev didn't fix this for me. Changing line 439 in date_api_filter_handler.inc from

    $complete_date = date_fuzzy_datetime($this->value[$prefix]);

to

    if (isset($this->value[$prefix]))
    {
      $complete_date = date_fuzzy_datetime($this->value[$prefix]);
    }
    else if (isset($this->value['default_date']))
    {
      $complete_date = $this->value['default_date'];
    }

Fixed it for me.

Hello.

I also have had issue with the 'now' feature. My goal is to simply add an 'up and coming' list of events on my site.

Anyway I just tried the fix that omerida posted and it worked fine for Drupal 6.10 and Date 6.x-2.0.

Thanks omerida and always thanks to KarenS for all the work!

Hello,

This bug is really critical,

Solutions #40 and #48 don"t work for me...

I have 20 date fields, it's very critical problem for me.
All nodes created after february 24 have the 01.01.2009 bug. (only empty fields sure).

I'm not a develloper, I can't find a solution myself.

I'm sure Karens will ^^ we have just to wait...

Thanks Karens :)

Everyone who is still having a problem should try this using the latest -dev version of Date, Views, and CCK (and Calendar if you use it). I cannot reproduce any problem in the latest code and I can't issue the fixed releases unless people confirm it is working. You need the latest -dev of Views and CCK because they have changes that could affect this. Both of them are due for new releases very soon, but for now you can get the fixes in -dev. After updating, be sure to clear all the caches (there's a button to clear the caches at admin/settings/performance) and run update.php to be sure there are no updates needed.

If there are still problems using the latest -dev versions of all these modules, then I need to know exactly what kind of fields and views you are creating by showing me exports of the fields and the views.

The solution in #45 is exactly the way the system is supposed to work, it was put into a theme so you could override it to say something else or say nothing. And that is a different issue that should not have been added into an issue that is already completely polluted by non-productive flames and complaints.

@webstylemedia, please quit telling me to TEST TEST TEST as though I'm too stupid to know that things need to be tested or too lazy to do it. If you repeat that one more time I'm going to just close this issue and any others you try to open because I'm tired of responding to it. If you don't know how to write patches there is no way anyone is going to give you cvs access, so you should not be surprised about that. Anyway, 'contributing to the community' doesn't mean committing code to cvs, it means providing patches, making constructive comments, providing detailed information about how to replicate the problems you see, doing some debugging on your own and reporting the results, etc. And you haven't done any of those things in this issue.

I have the lastest -dev version of Date, CCK, Views, Calendar. But I have the bug with nodes where Views and Calendar aren't used.

I'm using date cck fields and if they are no values, until to not display the date cck fields, 01.01.09 is displaying.

Date cck fields settings:

Text field with custom input format
Default value : Blank
Default value for To date : Blank
Numer of values:1
To date: Never
Granuality: Year, Month, Day

If I edit nodes with 01.01.09 bug, 01.01.09 is set into cck date fields where I haven't set a value. No way to erase it, 01.01.09 come back anyway.

These date cck fields are directly into nodes. No views here...

If you need something else... :)

Thanks

ps I only have this problem with nodes created since 01/03.

Hello, KarenS!

Sorry if I hurt you.

Can you at least write on the project page that these new updates are too much buggy and you recommend people do not update module and to use a latest available release candidate before fixed number 2.0? Btw what version it was? rc6 if I am not wrong?

Regarding help you to find it out - what info do you need from me? My sites have more than 60 modules - I doing updates to stable release versions regulary. Last time I made update of around 10 modules + updated a core drupal to d6.10.

What info do you need from me? All modules are latest.

I thought I already explained process how error appeared at the end of post #40.

Regarding CVS access - I don't need it - it just was an answer to Ron Williams about why I have so few posts. You, KarenS, just told me again more and more rules ("Anyway, 'contributing to the community' doesn't mean committing code to cvs, it means providing patches, making constructive comments, providing detailed information about how to replicate the problems you see, doing some debugging on your own and reporting the results, etc") - that is one more reason why I don't have any wishes to contribute.

Sorry, KarenS, please don't close this thread because others need a help. I don't have a problem after your fix in first dev version + All Day gone after my fix #40. Also I don't use Views (except 3 not important pages) - I use a custom module with custom queries for performance improvements.

I still think you built a very good module and really I can't live without it and without your work, so please don't be angry on me. All I wanted is just big red notice on the project page that NEW UPDATE IS DANGEROUS!

Thanks and sorry.

PS. Will not write anymore on this thread so please don't close it for others and don't be angry. Everyone make mistakes.

I had the "2009-01-01"-problem after updating to date-6.x-2.0 and calendar-6.x-2.0. Switching to date-dev (actually, only the patch mentioned in comment #31) solved it without need to do anything else.

My filter is not exposed and I use Views-6.x-2.3 on PHP 4.3.11. At first I used CCK-6.x-2.1 (rather old now) and then I updated to CCK-6.x-dev, still working fine. I can attach the view export if desired, but as things work for me I guess only people who still are seeing the bug need to give more info.

@webstylemedia, OK, apology accepted. But I disagree that this update is dangerous, I had much much worse problems in rc6 and no problems at all in the latest release, and I have been working with many many other issues about things that were badly broken in rc6 and fixed in the latest code, so I do NOT think the solution is to go backwards or to warn people away from this release even though there may still be a bug in it.

I still cannot reproduce the bug, and emok cannot reproduce the bug. I am not saying there is no bug, just that it's unusual enough that I cannot reproduce it, and it does not affect everyone.

The end of post #40 is about how to hide the 'All day' text, which is not what this issue is about. Junro's post at #52 provides the kind of information I was looking for -- exactly what kind of field was used and how to reproduce the problem. I'll see if I can get the same results using that information.

Hi,

I installed the -dev version because of this issue ; but my own problem is not fixed : my date fields' default value is blank (not now), and the fields (when not completed) are automatically filled as "2009-01-01..."

(if I set the default value to now, the fields have a correct value ; but I need a "blank" value...)

Thanks,

@ iko, it seems to be exactly the same problem than me, see my comments.

I can confirm the error.
I set up the current release version of views, cck on a fresh drupal install.
I've created a custom node with date fields and made a view for it with a filter.
So I have exactly 1 node in the system. There where no module updates.
Using the filter the date in the query was set to 2009-01-01.

Now I've installed the -dev version of date.
The error is gone with a hidden filter, but if I expose the filter now the date in the query has the right values for month and date, but the year is set to 0009 instead of 2009.
If you press the apply button the date is set right.
So I suspect there is still something wrong with "now", since this was the default value I chose.

Hope this helps somehow.

SELECT node.nid AS nid,
   node_data_field_publish_until.field_asof_value AS node_data_field_publish_until_field_asof_value,
   node_data_field_publish_until.nid AS node_data_field_publish_until_nid,
   node.type AS node_type,
   node.title AS node_title,
   node_revisions.body AS node_revisions_body,
   node_revisions.format AS node_revisions_format,
   node_data_field_publish_until.field_image_fid AS node_data_field_publish_until_field_image_fid,
   node_data_field_publish_until.field_image_list AS node_data_field_publish_until_field_image_list,
   node_data_field_publish_until.field_image_data AS node_data_field_publish_until_field_image_data,
   node_data_field_asof.field_asof_value AS node_data_field_asof_field_asof_value
 FROM node node 
 LEFT JOIN content_type_news node_data_field_publish_until ON node.vid = node_data_field_publish_until.vid
 LEFT JOIN node_revisions node_revisions ON node.vid = node_revisions.vid
 LEFT JOIN content_type_news node_data_field_asof ON node.vid = node_data_field_asof.vid
 WHERE (DATE_FORMAT(STR_TO_DATE(node_data_field_publish_until.field_publish_until_value, '%Y-%m-%%dT%T'), '%Y-%m-%%d') <= '0009-03-10') OR (node_data_field_publish_until.field_publish_until_value IS NULL)
   ORDER BY node_data_field_asof_field_asof_value DESC

@iko, Junro & Andreas Wolf

• As your problem is a bit different (you say it is not fixed by this patch) I guess you better open a new issue, with an appropriate title.
• You should also include an export of your date field and an export of you view! Without these two exports debugging will be almost impossible.
• In the new issue you should link to this issue to make clear you are aware of this thread (if you write [#issue-number] as described below the issue number will be turned into a link and the link text will be the title of the issues).
• After creating the new issue you can link to the new issue from this thread to help other users searching for the same info.

ok, here the new issue

When Date CCK Fields are empty, 2009.01.01 is display

So, this issue should be "Fixed" I think.

tu as été plus rapide que moi Junro ;-) field with "blank" default value automatically filled as "2009-01-01"

so... two issues for the same bug...

erf lol tant pis, je vais mettre le mien sur duplicate. Le tien est mieux expliqé

samesame like iko

The latest code from the DRUPAL-6--2 branch resolves this issue for me.

KarenS, your efforts are truly appreciated.

Running Views 2.3, CCK 2.1, and Date 2.0 I can replicate this problem. The dev release of Date fixes it. Moving back to fixed.

Hi,

Although the dev branch from 2009-Mar-09 fixes the now problem, it still does not work correctly when one uses a date modifier like now+1 or now-5. Then it just returns the now value and totally ignores the modifier.

I'd like to confirm that the fix in -dev solves this issue for me. As it seems to be an important issue to many of us, would this fix alone maybe warrant a minor update of the module (2.0.1)?

Thanks!

If you change the format from select to text the default will work without switching to the dev version.

Karen, you are a star. If I lived next door I would buy you a beer (or 3).

I appreciate the effort, many thanks.

I have 'now + 7days' date filters happily displaying correct rounds within my football website. The latest dev version for D6 works a treat.

-dev of 3/18 breaks this again for me. When I edit the view everything looks fine: dates are from now to now +6 days. See coming-events-view-edit.png. But the block itself thinks today is January 1: see coming-events-block.png.

http://drupal.org/node/404272 is a duplicate of this. Subscribing to this thread. Also running into the same issue on a view with a date filter.

#67 if you're using a modifier like 'now +5' it won't work, you have to tell it what kind of units, the pattern is 'now +5 days' or 'now -90 minutes'.

Everything works absolutely fine in the latest -dev version of Date and Calendar.

Please do *not* reopen this issue, it's totally polluted by confusion over which version is being used when and what problems were in existence are different points in time. If you have a problem in the latest -dev code, start a new issue.

getting the same issue. I will upgrade to -dev while I wait for latest version.

While the dev version fixes the basic problem for me on standard comparisons, it still seems to fail on "between" type ranges. Instead of giving a less than current date on the end range, it has =2009-01-01. I avoided this by simply having two filters, one less than and one greater than, but it seems that the fix in -dev may not be complete.

#70 worked a treat for me, I didn't have to switch to the dev version

i upgraded to 2.1 and it didn't work again :-(.

whats going wrong?

thanks

strauch

set status to active

Please do *not* reopen this issue, it's totally polluted by confusion over which version is being used when and what problems were in existence are different points in time. If you have a problem in the latest -dev code, start a new issue.

Please read the new TROUBLESHOOTING tips at http://drupal.org/project/date.

This is fixed in *-dev*, no one said it was fixed in 2.1.

Mhhh how does the development work? i thought the dev version will finished in the next release. As example 6.x-2.0 is release and 6.x-dev has the bugfix now 2.1 is released on which codebase is the realase, when it is not the dev version?
When will this fix is back in the release version. it is for me unknownable why this bug isn't fix in the release? the troubleshooting doesn't help me. sorry all the things works in earlier version i don't understand why the last release doesn't work the release is only 1 day old?!

should i open a new bug report?

Releases like 2.0 and 2.1 are released and never touched again so the only time they are 'the latest code' is at the moment they are released. The next fix after that goes into -dev, which then becomes 'the latest code'. It doesn't matter how old 2.1 is, there are fixes since it was released and those fixes are only in -dev.

The next release will include all changes since the last release, then we start over again where that will be the latest code only until there is a bugfix that goes into -dev.

So the -dev version is always the newest code, every other release gets outdated immediately.

This is fixed in *-dev*, no one said it was fixed in 2.1.

The release notes for 2.1 say that it's fixed in 2.1.

@Karen,

ok but when 2.0 released there was the first time the bug is present, the next dev Version after the release is bugfixed, i installed this dev and didn't updated the next dev, because i thought in the next release this bugfix is included. Now 2.1 is released and the bug is there again, what happend to the bugfix?

or can't i use the word now and have to use today, or is it translated in the new version, and i have to use the german word (jetzt)?

Using 'today' instead of 'now' worked for me (under the view - Filters), without having to go to the dev release.

Everyone please always TEST, TEST, TEST on your own production sites. Never upgrade modules on a 'big huge live site' w/o properly testing them yourself.

There seems to be some conflicts with the internationalization module. My upcoming block works fine in English, but not in other languages.

Unfortunately using 'today' does not work with me with the 2.1 release. The 2.x-dev release has other bugs. Can someone point me to a working version?

I noticed this didn't make it to 6.2.2 per its release notes. (But I was impressed at the number of fixes you implemented in 6.2.2!!)

Could we get an idea of when this will make it into a release? Thanks!

Have you still got this problem??

I'm still on a DEV version because per per #81, it's not fixed in 2.1, and 2.2's release notes don't say this issue is fixed.

You should try the 2.2 version... There are not all issues fixed in releases notes I think.

Thanks, but I am going to wait on confirmation from KarenS. This issue contains no .patch files, so I cannot verify for myself without backing up my database and installing the new module. (Have to back up because if the new version does not contain this fix, I have to revert to my prior state.)

I'm using Date 6.x-2.2 and "now" filtering works for me, thanks KarenS! As far as I can tell this is solved for good.

Please do *not* reopen this issue, it's totally polluted by confusion over which version is being used when and what problems were in existence are different points in time. If you have a problem in the latest -dev code, start a new issue.

grendzy: This query is not why Karen requested the issue be closed. This is germane.

This issue is closed. Leave it closed. If there are still problems in the latest -dev code, they need a new issue. The way you can tell that this issue is too polluted to use any more is that when you refer to 'this problem' or 'this fix', it's impossible to tell exactly what you mean. It is a waste of time to keep saying vague things like 'This is still not fixed', which is not enough information to respond in any way.

The original problem as reported for version 6.x-2.1 should be fixed. If it is not, I need a new issue that 1) is based on the 'latest code' (see the project page for the definition of that, this issue is for version 6.x-2.1, which is definitely *not* the latest code), 2) makes it clear whether the troubleshooting steps on the project page have been tried, and 3) identifies exactly how to reproduce any remaining problem (which will probably require at least an export of the view and and export of the date field with a clear explanation of what you did, what you expected to see, and what you saw).

Thank you!

THANK YOU

thankyou.