Closed DylanBaker closed 3 years ago
@fivetran-joemarkiewicz Got a first draft of this for your review.
My personal view is that we should only incorporate the timezone when we are 'date_trunc'-ing to something that is not a timestamp. I feel we should leave timestamps as UTC, and let BI tools (or users) do the final mile there if they prefer.
Therefore, I have (1) created a new macro that takes timezones into account and (2) replaced column references in that macro wherever we were converting a timestamp to a date, month, quarter, week, etc.
Example config looks like:
vars:
stripe_timezone: 'America/New_York'
TODOs:
Are you a current Fivetran customer?
Dylan, Fivetran
What change(s) does this PR introduce?
This PR aims to bring this package closer in line with reporting metrics that can be seen in the Stripe UI. The issue is that when aggregating to day, week, month or quarter, Stripe converts the timestamps from UTC to whatever timezone the user prefers. This PR makes the same transformations.
Does this PR introduce a breaking change?
Is this PR in response to a previously created Issue
How did you test the PR changes?
- [x] CircleCi - [ ] Other (please provide additional testing details below)