Views range should let you use absolute and relative in the same range

I agree, that would be a useful feature.

And how about this: I think it would be great if the range can dynamically adapt to the available values. For instance, if you have a database with students and their date of birth, the select box would only list years box in which one or more were born.

It appears that the date api function that does the conversion is robust enough to accept either as a +3 or 2009 formats. The views argument and filter handlers were being more restrictive on their validation. If there is a reason behind having a more restrictive validation, then this patch is not valid.

Patch: allows the date year range in the format -9:+9, 2005:2010, -9:2010, or 2005:+9'
Affected Files:

• includes/date_api_argument_handler.inc
• includes/date_api_filter_handler.inc

Thanks recrit, I will try to test your patch soon. I hope it will also accept combinations with 'now' in it, like 2005:now and now:+5, but I guess I'll find out when I start testing :-)

the date api function date_range_years does the conversion - it does not explicitly accept 'now' as a valid expression and the views validation does not either. However, 'now' can be accomplished by entering '2005:+0' or '-0:+5'.

Thanks, this patch works great!

@marcvangend

As for your other feature request (the select box only listing options for while results exist), there's already a component of the Views hacks module that is supposed to offer this functionality for all select fields: Views Selective Exposed Filters

Unfortunately, it doesn't yet work for the Date filter, but I think it's the module where your solution would come from. I've re-opened an issue in that queue, so feel free to comment on it if you're also looking for a fix:
#787904: Views Selective Exposed Filters does not work with date filters

Cheers!

I'd rather not leave a production site with a patch and it looks like the patch only allows the form to validate, so I gave editing the exported view a try. My views are all in separate files in a custom module and the line controlling the date range looks like this:

'year_range' => '1933:2010',

I edited this to instead be:

'year_range' => '1933:+0',

Now, my view loads the correct years in the exposed filter. Can you see any reason this is a bad idea?

Here's a patch updated to work against 2.6 that should work with drush_make. Works fine for me. While the validator isn't a liberal as the underlying code technically allows, it's a start.

It's a simple validator change that works as indicated above, so any chance of getting a commit on this?

It was always my intention that this would work, but my regex chops weren't up to the task. Sorry for getting to this so late, but finally got it committed.