Hello, I have been combing the timezone documenta...
# gooddata-cloud
j
Hello, I have been combing the timezone documentation and messing around with the different settings in terms of the hierarchy and no match seems to give me what i want: https://www.gooddata.com/developers/cloud-native/doc/cloud/customize-appearance/manage-timezones/ I am trying to support a platform that is generally accessed from multiple different timezones. Our dates are stored in UTC to support this intentionally, that way users can easily make timezone conversions based upon their client / browser. Am I reading correctly from these docs that this desired outcome is not possible with GoodData? Would every User need to set their own timezone settings for viewing the data?
t
Hi Jake! Thank you for your question, I believe that what you are trying to achieve should be possible. However, you are right, that TZ settings would have to be applied on a user level (probably by you or an admin of the environment). So 1) user would have to be provisioned to GoodData 2) you would have to somewhere gather the information about the TZ of the user 3) you would have to pass the information about the TZ to GoodData using the APIs mentioned in the documentation you shared.
j
Hi Tomas, thanks for the response. I have since looked at these API calls and got it partially working. Though I am a bit confused in terms of our use case, which seems to be pretty common, but I may be mistaken. On a single workspace, we will have users from different timezones who also travel and access the workspace from different locations. Ideally, we would like to go based off of the user's browser's timezone. Since, when looking across multiple businesses that are also on differing timezones, seeing in local time would make the most sense. Any ideas / thoughts / best practices on this approach? Thanks
t
🙂 great that you are making progres! The scenario is definitely interesting, but to be honest, not sure how common it is. Quite often we see even Workspace level setting being enough. The reason being that some level of consolidation usually leads to better understanding of what the data actually means. In a scenario where TZ is applied on individual user level, you may sometimes arrive to situations where “last 7 days” or “last 24 hours” would mean something else for 2 different people. It may of course be desired, but in some cases it could also cause confusion. I can imagine, that flexibly changing the TZs of the reporting based on the movement between TZs could even add to those confusion levels. However, this is just a general point around the use case, not to be treated as a discouragement shall you absolutely need it. As for the suggestions, I will probably try to research whether there is a simple way to extract the browser location of your users and programatically utilise this information. Since the APIs are there to set it up, you should be able to change the JSON body programatically and apply different TZs based on your needs. But like I hinted at before, it is always a good practice to keep the end user experience and data clarity in mind 🙂
j
Okay, we will bear what you have said in mind. Much appreciated Tomas!
🙌 1