Add tests for date field filtering

Do you use the Date module?

That's gonna be a challenge. I can not promise anything any time soon. I will try to slot this in some time in June. (I will check with my boss and if it's a priority for 10gen then obviously it will get done ASAP but he didn't indicate anything like that) My priority right now is entityreference.

Just like that and it works? Wowsie. Nice job. I havent yet applied but don't you need a field handler for proper output options?

I do not mean the filter, I mean display settings: field (which I think is the default) and then add field. I will check myself this the weekend if you don't get to it.

Oh sorry: the issue is about filter handlers and I was talking field handlers. Will take another look today.

Doesn't apply cleanly to the latest version of efq_views

patching file efq_views.info
Hunk #1 succeeded at 33 (offset -6 lines).
Hunk #2 FAILED at 42.
1 out of 2 hunks FAILED -- saving rejects to file efq_views.info.rej
patching file efq_views.views.inc
Hunk #1 FAILED at 222.
1 out of 1 hunk FAILED -- saving rejects to file efq_views.views.inc.rej
patching file handlers/efq_views_handler_filter_date.inc
patching file handlers/efq_views_handler_filter_field_date.inc

An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: /admin/structure/views/view/event_listing/preview/page/ajax
StatusText: OK
ResponseText:
( ! ) Fatal error: Call to undefined function efq_views_op_prepare() in modules/efq_views/handlers/efq_views_handler_filter_field_date.inc on line 5
Call Stack
#TimeMemoryFunctionLocation
10.0001725736{main}( )../index.php:0
20.487164865064menu_execute_active_handler( )../index.php:21
30.499867032096call_user_func_array
( )../menu.inc:516
40.499867032520views_ui_build_preview( )../menu.inc:516
50.510467569848views_ui_preview( )../admin.inc:954
60.554370447760view->preview( )../admin.inc:176
70.557470598800views_plugin_display->preview( )../view.inc:1360
80.557470598848view->render( )../views_plugin_display.inc:2673
90.557470598896view->execute( )../view.inc:1184
100.557470598896view->build( )../view.inc:1116
110.576872112904view->_build( )../view.inc:987
120.577072114616efq_views_handler_filter_date->query( )../view.inc:1098
130.577172121752efq_views_handler_filter_field_date->op_simple( )../efq_views_handler_filter_date.inc:60

Date module support has been added although it isn't using anything from this patch. Tests would be welcome.

I've re-rolled a patch that adds granularity and other date functions to the date filter.

I've also run into the need for granularity, etc. in the date filter. I applied the patch from #14 and discovered that the patch only helps in the case of datestamp fields (aka Date (Unix Timestamp)).

I'm new at working with Views handlers, but it looks like the issue is in the op_simple() method where strtotime() is called on $value. This, of course, converts the value — with which we're performing the EFQ — into a Unix timestamp. If your field is a type of date field that is not datestamp, the query will likely return nothing.

To get around this, I'd recommend a few changes to the patch.

In op_simple(), add a switch statement to treat $value differently, depending on field type:

function op_simple($field) {
    $raw_value = $this->get_filter_value('value', $this->value['value']);
    
    switch($this->date_handler->date_type){
    	
    	case DATE_DATETIME:
    	  $value = $raw_value;
    	break;
    	
    	default:
    	case DATE_UNIX:
    	  $value = strtotime($raw_value);
    	break;
    }
    
    return $value;
  }

This, of course, only helps in the case of datetime fields — the iso_date type should be added, as well. I did play with that one for a bit, but did not make any progress.

I also noticed that the init() method doesn't discriminate between type of date field either. Therefore, I'd recommend moving the creation of the date_handler after the call for field info:

function init(&$view, &$options) {
    parent::init($view, $options);
    module_load_include('inc', 'date_api', 'date_api_sql');
    
    if (!empty($this->definition['field_name'])) {
      $field = field_info_field($this->definition['field_name']);
      if (!empty($field) && !empty($field['type'])) {
        $this->date_handler = new date_sql_handler($field['type']);
        $this->date_handler->date_type = $field['type'];
      }
      $this->date_handler->db_timezone = date_get_timezone_db($field['settings']['tz_handling']);
      $this->date_handler->local_timezone = date_get_timezone($field['settings']['tz_handling']);
    }
    $this->form_submitted = FALSE;
    $this->date_handler->granularity = isset($options['granularity']) ? $options['granularity'] : 'day';
    $this->format = $this->date_handler->views_formats($this->options['granularity'], 'sql');

    // Identify the base table for this field.
    // It will be used to call for the right query field options.
    $this->base_table = $this->table;

  }

I'm not certain whether this changes much, but seems to be a step in the right direction if the code is depending on a date_handler.