The field formatter of the date field already allows to filter multiple values by a date range, if the field cardinality allows more than one value.
However currently it seems that the format for handling those range configurations is a bit special.
The filter values are processed by
date_sql_handler::arg_replace() which provides its "very own syntax" to create a date based on the ISO 8601 notation.
I actually don't know why it does this, instead using the relative date formats provided by php.
Especially since there's no db query involved in
But this just a side-note :)
The current notation is limited related to the usage of relative dates. It supports the usage of
now which is handy but there's nothing like e.g.
In my concrete scenario I've to show the whole day all the dates of from today midnight (00:00:00) to tomorrow midnight.
Unfortunately with the current notation I need to know how many hours/minutes/seconds are past since 00:00:00 of today.
Here it would be great to have support for php's relative date formats.
For now I've created a patch which allows you to select which notation has to be used. Even if I'm quite sure that the usage of
date_sql_handler::arg_replace() could be fully replaced in this particular case.
By default the new code uses to current notation, that way it's fully backward compatible.
- Decide if the usage of
date_sql_handler::arg_replace()is really applicable in this case.
- If yes, shall we really integrate the notation switch as currently in the patch or extend
date_sql_handler::arg_replace()to support all relative date formats?
- If not, rewrite the code to use php's relative date formats only. And check if an update hook is necessary.
User interface changes
The current patch introduces new radio elements in the field output formatter in the case it has a cardinality > 1.