This article is from 2018. What is dbt’s perspective on time zones (and roll-up aggregates to dates or months) with the dbt semantic/metrics layer?
That is a great question! When it comes to your models, I think the guidance in that article is sound. Personally, I’d go one step further and advise folks to keep their analytics time zone agnostic from as close to the data source as possible - normalize everything to an agreed-upon time axis, and only adjust for time zones on display. Of course this will not work for everybody, but if it works for you it will simplify a lot of things, because time zone management is absurdly difficult to get right.
The semantic layer, of course, cannot assume that all of our users will be able to follow the preferred “remain timezone agnostic” approach to metric queries. Depending on the context end users might need to do aggregations adjusted for the local time of the querying user, or aggregations adjusted for the local time where the input events occurred.
As of right now the semantic layer does not support custom time zone configuration, which means we cannot fulfill such queries, but it is something we will need to support. You can follow along with (or weigh in on!) the open issue at [Feature] Support TimeZone-aware time dimension types · Issue #733 · dbt-labs/metricflow · GitHub
Once that feature is released I will continue to advise people to stay away from aggregation-time time zone adjustments if at all possible, but if that is not possible at least the semantic layer will provide some mechanisms for getting timezone-aware metric results.
1 Like