views_handler_field_date for custom module outputs as if default UNIX date type (everything's 1969)

OK so, scratch the earlier issue. But there's still the problem that any custom fields defined in modules (regardless of the sql_type defined in the hook_date_api_fields) are output as if they were UNIX dates. Its seems that only the filter recognized it as the correct DATE_ISO type, whereas it tries to display it as DATE_UNIX (the default for the views_handler_field_date handler).

The short-term fix is to actually convert my date from ISO to UNIX in the database table, but it doesn't solve anything.

I'll update if I figure anything out.

Thanks for the reply Karen, but as I said above, I've used hook_date_api_fields, but it only affects the filter handler, not the field handler (apparently?). Unless perhaps I'm implementing it incorrectly:

function date_api_date_api_fields($field) {
  $values = array(
    // The type of date: DATE_UNIX, DATE_ISO, DATE_DATETIME.
    'sql_type' => DATE_ISO, 
    // Timezone handling options: 'none', 'site', 'date', 'utc'.
    'tz_handling' => 'none',
    // Needed only for dates that use 'date' tz_handling.
    'timezone_field' => '', 
    // Needed only for dates that use 'date' tz_handling.
    'offset_field' => '', 
    // Array of "table.field" values for related fields that should be 
    // loaded automatically in the Views SQL.
    'related_fields' => array(),
    // Granularity of this date field's db data. 
    'granularity' => array('year'),
  );
  
  switch ($field) {
    case 'results_students.year':
    case 'results_schools.year':
      return $values;
  }
}

PS - You're awesome.

It think I just ended up giving up on trying to display it, since filtering was my main objective (and that worked fine).

I'd suggest trying different timezone and granularity settings, and that might help sort out the bug.

Still running into this over a year later. Has anyone had any success in navigating this? I'm thinking it must be a misunderstanding on our part, as I can't imagine it being so quiet here otherwise.

Anyone have any thoughts as to what part of the setup might be missing?

Errr...

Just did a grep, and there doesn't seem to be a module_invoke_all('date_api_fields') bit anywhere in the Date module directory... just a module_invoke_all('date_api_tables')...

Could the reason it's not firing be because it doesn't exist? Isn't that function needed to create a hook? module_implements is used in one place, but I don't think that has anything to do with hooks... right?

Ok, so just did a backtrace from date_api_date_api_fields(), which is supposedly called by hook_date_api_fields() (which I would've presumed was module_invoke_all('date_api_fields')...), and it's looking like it's actually called by _date_api_fields().

Seems that this is where it happens:

    // Allow custom modules to provide date fields.
    // The is_a() function makes this work for any handler
    // that was derived from 'views_handler_field_date'.
    elseif (is_a($handler, 'views_handler_field_date')) {
      foreach (module_implements('date_api_fields') as $module) {
        $function = $module .'_date_api_fields';
        if ($custom = $function("$table_name.$field_name")) {
          $type = 'custom';
          break;
        }
      }
    }

So I guess it uses this instead of module_invoke_all(), but this only gets called when a filter is attached to a view, and not when just a field is, so I don't get how the field would ever know how to process the date data.