Filters causing weird DateTime error

[mangotree]

After migrating from 2.1 to 3 I get the following error when trying to filter data in the list view (or in advanced search)

500 - DateTime::__construct() [datetime.--construct]: Failed to parse time string (Dennis R. Davis) at position 0 (D): The timezone could not be found in the database

The "Dennis R Davis" is an example of the text I was trying to filter for in a text column.

Also, from much testing it appears that this error only occurs on fields that had filters applied BEFORE the upgrade. All other fields filter fine, with no error.

 

[cheesegrits]

Is that only happening when using "search all", or "advanced search"?

Try setting both "Include in search all" and "Include in advanced search" to No on your date element. In the Filters sections of the List Settings tab.

You may also find you get a weird MySQL error complaining about mixing colation types, once you get past that date error. if you do, typically you'll need to then do the same (disable search all) for any elements which are not textual (like 'id' elements, any field elements you have set to "integer", etc).

-- hugh

 

[mangotree]

Hugh, it appears that removing the date/time fields from the search all has solved the problem but its still a bit of a nasty bug that should be looked at. But thanks for the idea of doing that. It solved my immediate issue.

James

 

[cheesegrits]

It's a very difficult situation for us to resolve automagically. It stems from a problem with the J! date API we use, which has no graceful way of catching the error of trying to instantiate a J! date object on a non-date, rather it just blows up with a fatal error that can't be caught or handled in any way. And it's not as simple as just seeing if the input looks like a date ebfore we ask J! to create a date object for it, as the J! API supports PHP's "string dates", so you can ask for a date of "third day of this month" or "today plus four days".

We have tried various approaches for solving this, none of which have so far worked.

So until we find the magic bullet for this, we pretty much put it in your hands, by deciding for yourself which elements you wish to be included in a "search all" or "advanced search", depending on what you are searching for.

-- hugh