In our data environment, all date times are stored in UTC. However, specific customers have requested that the data in their dashboards be presented in EST. I see a Time Zone setting on an Account. IF this value is set for the account, will offsets be applied to the data being pulled into the system?
Is there any other way that we can apply appropriate offset logic (including taking into account daylightsavings and such) to have the data as presented reflect EST?
First off glad to see that your system was set up using UTC, this is a best practice. It might be confusing at first but then when you have to compare times on what happen on two servers that are in different location and using local time it makes thing all to easy.
I just made a metric set that had a time entry on it then noted the time it had and then changed my time zone to something different and it did not change what time was displayed.
I just search support for “Time Zone” and the only thing I found was that you can set it, but not what setting it does for a user.
I would contact support.
Hi Paul - James brings up a good point, this is probably something that you should consider asking our support team. Please feel free to reach out. support@dundas.com
For anyone else experiencing a similar issue:
Dundas does not natively convert to a client’s local time zone. The main reason for this is that even a built in conversion process would require very similar overhead to just creating a calculated element, since each DateTime object would need to be converted from its server counterpart to the client’s time zone before being parsed into a string on a date preview/table. Additionally, even if individual data points don’t need to be converted into strings in the cases of some charts and non-tabular visualizations, the data points themselves would still need to be converted first. Due to the performance considerations above, datetime objects from a database are kept to their db server’s timezone and we give our users the option of creating a calculated element in such cases.
DateTime.ToLocalTime, uses the client’s machine’s time zone as the reference for which to convert the datetime object to. The data is already defaulted on the db server’s timezone and it is being converted to the time zone on the client’s machine. Here is a sample from our support article on calculated elements, which contains a line that uses the aforementioned method:
Hate to bring up old threads but this was very helpful and a good thing to know. Had an issue where a data input created time wasn’t showing local time zone. Thanks to this article, created a calculate element to adjust for the difference and was on my way.