merged branch fabpot/timezones (PR #876)
This PR was merged into the master branch.
Commits
-------
f99504a changed the date filter behavior to always apply the default timezone, except if false is passed as the timezone
d3b0cbd merged branch jmikola/patch-1 (PR #845)
a6a1ef0 Avoid setting timezones on DateIntervals
Discussion
----------
changed the date filter behavior to always apply the default timezone, except if false is passed as the timezone
This PR is based on #845, and addresses issue #778.
Right now, the timezone management when using the date filter is counter-intuitive. When you pass a DateTime object, the default timezone is not applied, but in all other cases, it is.
This PR makes the behavior more consistent by always applying the default timezone (which is probably what users want most of the time), and this can be disabled by explicitly passing ``false`` as the timezone value.
This is a BC break but I think that not many consciously rely on the current behavior.
---------------------------------------------------------------------------
by fabpot at 2012-10-30T15:49:13Z
@jmikola Can you have a look at this PR and tell me your opinion about this change?
---------------------------------------------------------------------------
by jmikola at 2012-11-02T20:17:30Z
@fabpot: Will take a look at this tonight. I missed the notifications as I was offline for a few days.
---------------------------------------------------------------------------
by jmikola at 2012-11-03T04:09:54Z
I read through all of the issues and PR's and this looks reasonable. Are we missing a test case for passing in a DateTime object with `false` for the timezone? I do see one example where we render the current date using the `'e'` format string and provide `false` for the timezone, but that's it.
---------------------------------------------------------------------------
by fabpot at 2012-11-03T07:09:08Z
ok, I've added an additional test just to be sure.