Add date_in_tz filter.

[djwf]

I wanted to add a date filter that would allow setting the timezone, so I created this filter based on the date filter. There is a lot of duplication between this filter and the date filter, but I decided to keep things simple for now.

Example use is: {{ "13 Jun 2016 12:00:00 +0000" | date_in_tz: "%Y-%m-%d",-13 }}, which would result in 2016-06-12.

[djwf]

@johannhof: I've just finished (I think) the reverse tag as well: shall I put each filter in a new pull request? Or all filters into one?

[johannhof]

@djwf depends on your confidence in your implementation, the advantage with individual PRs is that it's easier to contain review issues, but I think doing one big PR should be fine in this case.

Thanks for your contribution! I assume I can close this in favor of #74?

[johannhof]

Oh actually reading the other PR it's probably better to review this one first. Apologies!

[johannhof]

Ok this looks great, thanks. (I love how Rust + Clippy + rustfmt make reviewing so easy)

One thing I'm a bit worried about would be adding too many (undocumented) filters to this. It's obviously great that people are contributing the filters they need but maybe we should hide all non-standard features behind a compiler flag. That could even be enabled by default but if someone really only wants the pure liquid experience they could disable the "extra-filters" feature.

Can you please hide this behind a feature flag and put that feature in the defaults? You can find examples how to do that here: https://doc.rust-lang.org/book/conditional-compilation.html

Thanks!

[johannhof]

Oh and thanks for adding so many tests to it!

[djwf]

I added an "extra-filters" feature and set things up so that date_in_tz is included in that feature - thanks for the pointer to the howto. I think this handles all the issues, but let me know if you've any others!

[djwf]

@johannhof I looked through the failed builds, but I'm not sure what to do to fix them. Let me know if it's something I did.

[johannhof]

Uh, good question. I retriggered it. :)

[djwf]

Thanks! However, it looks like something is broken in the appveyor builds, because now it can't even find curl.

[djwf]

@johannhof Any idea what might be causing the fail? I don't think the code is bad...

[epage]

I patched AppVeyor for cobalt.rs, I guess this needs the patch as well. I hope later today I can fix that

[epage]

Sorry for the delay, got my patch in. Travis will fail though on nightly because of clippy being broken again.

[djwf]

@epage thank you! @johannhof could you kick off another test and/or merge this? I'd like to work on some other stuff but don't want to lose track of this.

[epage]

One thing I'm a bit worried about would be adding too many (undocumented) filters to this. It's obviously great that people are contributing the filters they need but maybe we should hide all non-standard features behind a compiler flag. That could even be enabled by default but if someone really only wants the pure liquid experience they could disable the "extra-filters" feature.
Can you please hide this behind a feature flag and put that feature in the defaults? You can find examples how to do that here: https://doc.rust-lang.org/book/conditional-compilation.html

@johannhof can we get your recommendation on this documented in CONTRIBUTING so we set expectations (and remember them) when other people contribute features?

[johannhof]

Good idea! We should also document this flag in the README

could you kick off another test and/or merge this? I'd like to work on some other stuff but don't want to lose track of this.

I added you to the org, you should have kick-off-build rights on AppVeyor now (I also triggered a build though).

[johannhof]

Errors because of a caching problem. Should be good to go.

[djwf]

Thanks! I'm traveling now, but will start the next project from the needs-help section this week.