date_api_filter_handler used as view filter handler but it doesn't exist.

A little more poking around at this problem leaves me a little confused. I need some clarification on this.

It seems the date_api changed the name of the handler to date_views_filter_handler.
At first glance that would be an easy fix but its not "the right thing to do". What if the date_api changes the name again for some reason.

The next point of note is that date_views_filter_handler gets found any way so why hard code something there at all?

If date_api is not installed it returns views_handler_filter_date which seems like a viable alternative and possibly the correct thing to do but I'm not so sure.
I'm thinking this function does the "wrong thing" for each of the views handlers where the field type is datetime.

Correct me if I'm wrong.

$schema['fields'][$field_name]['type'] gives the MySQL table column type.
So 'datetime' is the MySQL type NOT the drupal type.
That being the case then there is no appropriate views handler for this type that I can find and, since the core team have decided 'datetime' is not portable, there isn't likely to be one.

Well, actually, there will be one. I need one and if I have to write it myself I will.

This is a bigger issue than it first appears, at least from my perspective.

I need Data to support MySQL type 'datetime'.
My question now is:

Is Data a MySQL specific module?

If it is then I'll hack around and add/fix the support where its broken. Perhaps it should supply views handlers for the MySQL specific types.
Perhaps the module name should be changed too?

If it's not MySQL specific I'm willing to consider forking it to create a MySQL specific module.

Perhaps it's best to create a MySQL specific sub module?

@joachim: Re. #2

> I think it's safe to depend on a module keeping the handler class name the same throughout major version lifetime, ie for the duration of 7.x-2.x.

Fair comment but it got missed this time. I don't know when it got changed though.

> Is that handler suitable? Does the date module handler provide more functionality?

At the moment, I have no idea.
This is where it all goes wrong for me.
I've adopted the table. Then set up the view via 'Configure Views' but no matter which handlers I choose the datetime fields show nothing when displaying the view.

I'm assuming that none of the view handlers available actually support the MySQL datetime type. What I don't know is if any of them are supposed to.
All of the handlers I have tried generate 2 errors for each field like this:

Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (line 1941 of /usr/share/drupal7/includes/common.inc).
Warning: date_format() expects parameter 1 to be DateTime, boolean given in format_date() (line 1951 of /usr/share/drupal7/includes/common.inc).

This is where I start guessing and making lots of assumptions that may be totally wrong and I could really use some help fixing my assumptions.

I assume none of the handlers support the datetime field.
I assume none of the handlers are supposed to support it.
I assume everyone is ignoring it since it's not supported by the core and the prescribed way is to use an int representing seconds since the epoch.

I can't decide if my assumptions are correct. If they are correct then the support needs to be added. If they're wrong then I need to help fix what is broken.
I desperately need some pointers on this.
The most obvious thing is that the Date module should support this but I'm developing the impression its only supposed to support internal Drupal types.
Since the Data module has indications of attempting support then it becomes my next candidate for fixing but Data is surely about the data, not the display of that data and since it doesn't provide any view handlers why should it provide any for this.
On the other hand the handling of 'datetime' fields in the code for Data is inconsistent, is that a bug?
The Schema module seems to be dealing with actual database schemas and types but it has no support for things not in core. Is that where it all breaks down?

As you can see I'm somewhat confused so I'm trying to deal with obvious errors until such time as someone can advise on the proper policy for this.

There is no doubt in my mind that Drupal needs to be able to do this, its a fundamental requirement surely but I just can't get my head round it properly and don't want to go doing a load of work fixing it in the wrong places.

Sorry, this is a bit long winded for a bug comment but I can't find an appropriate place to discuss this and you guys have been the most approachable to date.

A patch to remove the date_api_filter_handler reference since date_api_filter_handler does not exist.

Right. I'm on it. Its my very next task.