Avoid setting timezones on DateIntervals
merged branch jmikola/patch-1 (PR #845)

This PR was merged into the master branch.

Commits
-------

a6a1ef0 Avoid setting timezones on DateIntervals

Discussion
----------

Avoid setting timezones on DateIntervals

Edit: originally, I opened this to ensure the default Twig timezone was always set on incoming DateTime objects, but I came to realize why that behavior would be undesirable. The idea was prompted by this line from: http://twig.sensiolabs.org/doc/filters/date.html

> The default timezone can also be set globally by calling `setTimezone()`.

Anyway, I did notice an edge case where the code might call `DateInterval::setTimezone()`, so this PR attempts to correct that. Additionally, I added some tests for passing a DateTimeZone object to the `date` filter.

---------------------------------------------------------------------------

by jmikola at 2012-09-22T17:18:56Z

@fabpot: One question came up as I was looking through this a second time: if `twig_date_converter()` receives a DateTime argument, it will override its timezone regardless of the logic path within (either from the `$timezone` argument, Twig default, or the system default).

At first, I thought that it was redundant for `twig_date_format_filter()` not to utilize `twig_date_converter()`, but it looks like that was a careful decision; otherwise, there'd be no way to display DateTimes with their internal timezone. This PR would remove that functionality, so I need to reconsider.

Having said that, there does appear to be a bug in `twig_date_format_filter()` in that it could end up calling a nonexistent `setTimezone()` method on a DateInterval object. Would it be preferable to throw an exception or simply ignore the `$timezone` argument if the `$date` argument is a DateInterval?

---------------------------------------------------------------------------

by fabpot at 2012-10-30T08:56:31Z

I don't know if not changing the timezone on DateTime object was a conscious/careful decision or not. The documentation is not so clear about that, and there is even a bug report about this behavior: #778.

For consistency, I think we can always set the timezone and allow disabling that by passing `false` for the timezone.

Does it sounds good?
changed the date filter behavior to always apply the default timezone, except if false is passed as the timezone
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.
fixed CS