Currently the date filter always filters using the date fields default timezone handling. However, there are certain use-cases where you may want to filter by a specific timezone.
Example:
I have a content type with a date field with Time Zone Handling set to: Site's time zone.
I have views that display content listed for the current day. This displays the content for the current day using the site's timezone by default, and if users are allowed to change their timezone then filters by their timezone instead.
My use case is I want to also have a block that displays content for "6PM-10PM ET" (aka America/New_York) no matter what the users timezone is set to.
Here is another real-life example of a use-case which could be accomplished through this feature and allowing timezone to be an exposed filter:
http://www.nbc.com/schedule/
Comment | File | Size | Author |
---|---|---|---|
#22 | date-views-filter-timezone-1820304-22.patch | 8.34 KB | John Franklin |
#21 | date-views-filter-timezone-1820304.patch | 7.96 KB | asherry |
| |||
#18 | date-views-filter-timezone-1820304-18.patch | 6.92 KB | joelstein |
Comments
Comment #1
jojonaloha CreditAttribution: jojonaloha commentedHere is an initial patch that allows a View to set the Timezone for the filter.
Comment #3
elliotttf CreditAttribution: elliotttf commentedRe-rolling and adding the same logic to arguments that was added to filters.
+1 for this functionality.
Comment #5
bleen CreditAttribution: bleen commentedplayed 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)
Comment #6
cafuego CreditAttribution: cafuego commented#3: date-1820304-views_filter_timezone-3.patch queued for re-testing.
Comment #7
cafuego CreditAttribution: cafuego commentedRequesting 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.
Comment #9
cafuego CreditAttribution: cafuego commentedI've updated the patch with a change in date_views_argument_handler::get_query_fields()
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.Comment #10
vijaycs85Thanks for working on this. Patch in #9 looks good to me. but we may need to do a manual testing to make it RTBC.
Comment #11
justindodge CreditAttribution: justindodge commentedHey 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.
Comment #12
vijaycs85Lets add some test
Comment #13
podarokdue to #11
we needs testing coverage here
Comment #14
joelstein CreditAttribution: joelstein commentedThe 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.
Comment #15
joelstein CreditAttribution: joelstein commentedI 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.
Comment #16
vijaycs85thanks @jojonaloha. Changes looks good. We need some test (with failing test without code change, if possible) to RTBC.
Comment #17
joelstein CreditAttribution: joelstein commentedI'm not sure how or what to test, but I'm happy to write some tests if you point me in the right direction.
Comment #18
joelstein CreditAttribution: joelstein commentedFilters weren't always applying the customizable timezone settings, so the new patch improves upon this.
Still haven't had a chance to write tests.
Comment #19
asherry CreditAttribution: asherry commentedThis 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.
Comment #20
asherry CreditAttribution: asherry commentedhere 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.
Comment #21
asherry CreditAttribution: asherry commentedCorrection 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.
Comment #22
John Franklin CreditAttribution: John Franklin commentedThis 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 ofdate_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 valuetimezone_default_value()
chooses, otherwise we're always using the value fromdate_default_timezone()
.Attached is a patch that fixes the
timezone_default_value()
method to return the correct value.Edit: formatting
Comment #24
DamienMcKenna