Add ability to sort Views exposed filters SELECT lists in reverse

I agree that usability would be improved by allowing descending years, especially for those of us handling historical dates.

In #247877: choose sort order for select lists, which I've marked as a duplicate request, scedwar suggests

maybe by being able to reverse the logic in the "years back and forward" e.g. from "-100:+0" to "+0:-100" (this currently doesn't work).

subscribe

Changing version.

I'm also in need of this feature (requested it already at #343599: Years back / forward in descending order

An initial version of this change, to fix the year field, can easily be accomplished by adjusting the code in the date_parts_element function (D5 branch in this case). The "Years back and forward" field for the CCK element, and part of the base date form elements, sets the min/max years. If you specify these values backwards (eg. 0:-100), with no default value, then you get the years in the order we are looking for. Of course, the current code then breaks if there is a default value, and you only get the default value year as an option. The function mentioned above can easily detect the order and adjust for this.

Time permitting, I'll try to submit a patch for this.

This isn't a patch, but here is how to fix this...

Update the date_years_range() function in date_api.module (This was in revision 1.64.2.5.2.78).
from:

  if (!empty($value_year)) {
    $min_year = min($value_year, $min_year);
    $max_year = max($value_year, $max_year);
  }

to:

  if (!empty($value_year)) {
    // See if the range is in reverse
    if ($min_year <= $max_year) {
      $min_year = min($value_year, $min_year);
      $max_year = max($value_year, $max_year);
    }
    else {
      $min_year = max($value_year, $min_year);
      $max_year = min($value_year, $max_year);
    }
  }

Update the date_parts_element() function in date_api_elements.inc (This was in revision 1.49.2.1.2.47).
from:

      case 'year':
        $range = date_range_years($element['#date_year_range'], $date);
        $min_year = $range[0];
        $max_year = $range[1];
        
        $sub_element[$field]['#default_value'] = is_object($date) ? date_format($date, 'Y') : '';
        if ($part_type == 'select') {
          $sub_element[$field]['#options'] = drupal_map_assoc(date_years($min_year, $max_year, $part_required));
        }
        break;

to:

      case 'year':
        $range = date_range_years($element['#date_year_range'], $date);
        if ($range[0] <= $range[1]) {
          $min_year = $range[0];
          $max_year = $range[1];
        }
        else {
          $min_year = $range[1];
          $max_year = $range[0];
        }
        
        $sub_element[$field]['#default_value'] = is_object($date) ? date_format($date, 'Y') : '';
        if ($part_type == 'select') {
          if ($range[0] <= $range[1]) {
            $sub_element[$field]['#options'] = drupal_map_assoc(date_years($min_year, $max_year, $part_required));
          }
          else {
            $sub_element[$field]['#options'] = array_reverse(drupal_map_assoc(date_years($min_year, $max_year, $part_required)), TRUE);
          }
        }
        break;

As far as I can tell, this doesn't break anything. If I find some time, I'll grab a CVS checkout, rather than my tarball copy, and roll a patch.

And just in case anyone's reluctant to edit code, it's possible to reverse the order of an exposed filter, so long as it's absolute dates (not relative like "+3:-3", etc), but simply writing "2008:1995" or whatever as the date range. If you try it with relative, you get an error saying that neither relative nor absolute date ranges will work in that order, but for some reason absolute dates do still work.

Hopefully this helps someone!

@patcon - thank you!

you write ".. to reverse the order of an exposed filter" and so i was hopping you're not talking about view exposed filters and was happy to find out this works on D6 with select list cck date field perfectly.

I think this should be documented, and since this is possible not sure that "feature request" is still valid...

oops yeah... not only exposed filter, but any date field -- it was just that in my case. And yeah, wires do need to get uncrossed over this, and documentation and dialog need to align.

I'm switching the category to "task", as the user interface warning I mentioned above should be updated to reflect the fact that absolute dates can be ordered in reverse :)

Cheers all!

subscribe

Thank you rwohleb. The code in #6 is close but not quite right as it leaves the blank choice at the end of the select. Here's a patch to the date module that appears to do the job. Execute patch from sites/all/modules

Also, the

simply writing "2008:1995"

approach in #7 didn't work for me.

subscribe

patch in #11 needs review

Thanks, @dwightaspinwall. We tested the patch on a range of years. It successfully reverses the display of dates for any range of -0:-n. However, 0, +0, or any positive number does not validate as the first value in the range. (See attached image.)

I have re-rolled your patch against CVS. (It can be applied from right in the date module directory.)

A use case for wanting future year might be to allow users to search for upcoming events in 2011.

Thanks Ben. Good catch.

Making issue title more explicit, findable.

Has this patch been applied to DEV?

subscribe

will be nice for the D7 version.

Subscribe

Subscribe

Subscribe

Is this patch in #14 working ?? Can I use this to reverse the range in form api

Works for me and we use date pretty heavily.

I installed the patch and I tried the following code in the form api,but it's not working for me.

  $form['ed'] = array(
  '#type' => 'date_select',
  '#date_format' => 'm-d-Y',
  '#date_label_position' => 'within',
  '#date_year_range' => '-100:-0',
   '#prefix' => '<td> End Date : </td> <td>',
  '#suffix' => '</td></tr></table></div>',
  );

Its still showing the years starting from 1901 only instead of 2011 .

What am I doing wrong here or do I need to do anything after applying the patch.

Did anybody get this working on D7? I need to go from +1 year to 1950. Thanks

Coming back to this, it seems to me the issue is more fundamental but actually simpler than we originally treated it as being. There's a block of code that outright states, "We expect the $min year to be less than the $max year." and then reverses them if they're not. As far as I can see, no other functionality depends on this. All that really needs to be done, therefore, is to remove this block and update the in-code documentation and variable naming to reflect the eliminated assumption.* Here's a patch that does so—and makes a few small style improvements. Most notably, I discovered that when date_range_years() stretched a range to include a current value, it returned the years as strings instead of integers, as the function does otherwise; so I typecast them. I rolled my patch against 6.x-2.x-dev because that's where I had a ready test for the functionality. If the test bot likes it and it works for everyone, we can re-roll it against 7.x next; but hopefully this will get the ball rolling again.

* @KarenS, et al: I suppose this constitutes an API change, because it changes the behavior of date_range_years(). Can you advise on the implications of making such a change? Thanks!

Oops; I missed something. Here's an updated patch.

Sorry for all the noise, but I realized that filter and argument validation also assume an ascending date order and refuse to accept year ranges beginning with a positive number (e.g. +1:-5). This patch fixes the validation and related help text. (I tested the change to the filter handler. Since the argument handler code was identical I just assumed the same change worked for it, too. (Famous last words.) It would be great if somebody wanted test it, specifically.)

And now for the three years anniversary since the last patch, here is an updated patch against 7.x-2.x

It will not show positive options in the starting year or negative options in the ending year dropdowns, but if you select "Other" you can enter them manually.

I believe there may be a patch formatting issue in the patch in #32. I had to apply it using `patch -p1`.

This is a reroll of that patch which can be applied using `git apply ...`.

I am content that @georgir's patch in #32 (and my reroll in #33) does indeed allow Date ranges to be reversed. Changing the order inside my View did nothing until the patch was applied, and now it is in the desired (reversed) order.

Thanks, @georgir!

commited #32. Thanks

Patch #32 worked great for me on my current stable release of date (version 2.8). Glad to see it was also committed to dev.