This feature will help you change the timezone where your data is processed and displayed.
For example, if your business operates in Singapore, you will probably want every calculation to be handled in UTC+08:00.
The beta version only supports PostgreSQL, Redshift, BigQuery and Snowflake (we’re working on the other ones). For more information, please read our public doc here: Timezone Settings
If you would like to join our beta, please contact us via [email protected]
Thanks Di, this is awesomeee
Thanks, this is a great addition.
Could we add to the backlog though the ability to configure this by data source? We handle data for organisations from all over the world, so whilst {{yesterday}} might be OK for one data source based on a central time zone, it might not work for other data sources.
Hi David,
Would you mind sharing with us more details on your case, so that we can understand what you want to achieve so far:
Hi @di.hoang,
yes, we operate across many different timezones, and will always report based on the local timezone.
So for example, we currently have our Org Timezone set GMT+10 (Sydney AEST, though we’re currently in AEDT). The date here is currently 17th December 2021
Therefore if I run a report to show me the performance for the previous day (16th) with {{yesterday}}, I get the correct data.
However for my colleagues in the USA, it’s still the 16th, so if they ran {{yesterday}} , they will get actually get the ‘current’ date, and will see incomplete data. Instead, they would want {{yesterday}} to resolve to 15th, as that’s {{yesterday}} for them.
I see from your documentation that you to plan ‘dashboard level’ overrides
I’d happy to help test this when you’re ready - though would still say controlling this at a dataset level would be better (at least in our situation), as otherwise you can’t have multiple business units on a single dashboard.
Our current workaround to this will be to have a calendar table per-data source, which will contain a ‘isLatestDate’ flag, and filter on that flag.
Hi David,
Thank you for sharing your case. We really appreciate it!
As far as we understand, your business spans across multiple countries and your report viewers should retrieve data under their local timezones. Especially, you want to have multiple business units on a single dashboard.
Please let us know if we missed anything.
If it is your case, would you mind explain to us what you meant “multiple business units on a single dashboard”? Assuming that you have a dashboard with two widgets A and B, does it mean:
(1) The US users should see both A and B in US timezone while the Australian users should see A and B in Sydney AEST? Or
(2) A should run in US timezone while B should run in Sydney timezone at the same view?
We look forward to hearing from you.
Hi @di.hoang ,
yes you’ve captured that use case correctly, and to your final point, it would be option 2) - regardless of who is looking at the data (and where they are), if they ask for ‘yesterday’ they should get ‘yesterday’ relative to the business unit, as that ensures they get completed & most up to date data for each business uint, even if it technically means one business unit is a day ahead of the other.
A good example of this might be our operations support team; they’ll be monitoring all systems on a dashboard, and they’ll want to know ‘have we completed data processing for yesterday?’ It’s hopefully clearer from this example that ‘yesterday’ will always be in the context of the system being monitored, rather than the context of the person viewing the data.
Hi David,
Thank you for sharing your case. We really appreciate it!
As far as we understand, the timezone you want should be per record, not per account/dashboard/widget. For example, you create a report that shows all records from two branches US and Australia. When you add a filter ‘yesterday’, you would like to see all records that happened yesterday:
If it is your case, we are afraid that our Dashboard-level timezone might not perfectly but partially solve your issue. To be more specific, this setting will allow you to override the Organization Timezone at the dashboard level. We will let you know if the beta version is available, and/or we have some followup questions to understand more about your case.
Thank you for your patience and understanding.
Yes that’s all correct.
Dashboard level will partially solve it for us, as we don’t always mix timezones, but as you say it won’t completely solve it.
Being able to define it at a datasource level would certainly be the preferred way for us, so perhaps something to consider in the future? In the meantime we’ll use a separate control table to manage this.
Hi David,
Thank you for your confirmation.
Actually we have not had any plan to support timezone at data source level up to now (since timezones are a complicated beast, and different customers will definitely have different use-cases). Our upcoming plan is to release the Organization & Dashboard-level timezone settings first, then collect more feedback and use cases from all of you (to make sure that we’re on the right track).
Therefore, it’s difficult for us to confirm that we will support the data source-level timezone setting right now. However, we have already added your request to our backlog, and will get back to you if there is any further update on it.
We just want to let you know that our issue is really important to us, and we will try our best to enhance your working experience with our product in the future. Again, we really appreciate your patience and understanding.
