Allow a View Date Filter to Override the Timezone

Re-rolling and adding the same logic to arguments that was added to filters.

+1 for this functionality.

played with #3 last night and it works as advertised ... RTBC (apparently the failing test is due to #1835214: Automated tests failing - Exception thrown in Date2 migration)

#3: date-1820304-views_filter_timezone-3.patch queued for re-testing.

Requesting a re-test because git claims the patch no longer applies. That's not impossible, because I've committed some bugfixes before I looked at the feature request issues.

#3: date-1820304-views_filter_timezone-3.patch queued for re-testing.

I've updated the patch with a change in date_views_argument_handler::get_query_fields()

+++ b/date_views/includes/date_views_argument_handler.inc
@@ -192,6 +192,17 @@ class date_views_argument_handler extends date_views_argument_handler_simple {
         date_views_set_timezone($date_handler, $this, $field);

I've moved this line to below the logic that determines what to set $date_handler->local_timezone to. I've also modified that if block to default to the original behaviour if $options['timezone'] is not set, rather than setting a default first and then overriding.

Thanks for working on this. Patch in #9 looks good to me. but we may need to do a manual testing to make it RTBC.

Hey guys - I was giving the patch in #9 a try but having some issues.

I've got a page view with an exposed date filter, but I cannot seem to get the timezone setting to stick regardless of whether the filter is exposed or not, it always seems to be set back to the top default value when I check on the filter settings.

Additionally, changing the timezone for the filter seems to have no effect on my view results, and when debugging my view page I have a white screen - I found:

Cannot create references to/from string offsets nor overloaded objects in /includes/common.inc on line 6518

I'm using the latest version of views, and dev version of date. Drupal 7.21.

I can help provide more specific info if needed, debug/breakpoints/var dumps, etc, but right now I can't dive all the way in myself.

Lets add some test

due to #11
we needs testing coverage here

The value isn't saved since it's nested below the ['value'] part of the form. I'm rolling a patch right now that fixes this, plus a few typos and general code cleanup.

I fixed the issue of the value not persisting, which was the cause of the query not being altered. I also fixed a couple misspellings and did some code cleanup.

thanks @jojonaloha. Changes looks good. We need some test (with failing test without code change, if possible) to RTBC.

I'm not sure how or what to test, but I'm happy to write some tests if you point me in the right direction.

Filters weren't always applying the customizable timezone settings, so the new patch improves upon this.

Still haven't had a chance to write tests.

This patch didn't work for our particular setup, but it was a pretty good start in getting me there. Our configuration is using the string comparisons that are then sent to date_create - which was hardwired to call date_default_timezone_object.

I instead used the customizable date value, and it works great.

here is also a printout of the config that I'm using, just for reference. The field handler is set to UTC, and the current site's timezone is set to America/Los_Angeles.
Those can't be changed. And this view is needed as a comparison to see if the entity should be shown, not any date that actually needs to be displayed to the user. Hence the need to compare UTC to UTC.

Correction to my last patch, I didn't realize that potential values for the $this->options are going to be 'user', and 'date', and they need a little processing.

I noticed in two places there was processing to handle that, and I needed a third place, so I also made a helper function that would handle that processing.

This doesn't seem right. The date_views_filter_handler_simple::timezone_default_value() method changes $this->date_handler->local_timezone, but then returns the result of date_default_timezone(). Everywhere the method is called, it assigns the returned value to $this->date_handler->local_timezone, overwriting the change made inside the method. We want to preserve the value timezone_default_value() chooses, otherwise we're always using the value from date_default_timezone().

Attached is a patch that fixes the timezone_default_value() method to return the correct value.

Edit: formatting