Calendar Range Token Timezone

#1

The server hosting my Dundas BI instance has UTC Timezone. The Default Timezone in application config is set to UTC. The user’s dundas session timezone(dundas.context.currentSession.timeZoneId) is UTC. The user’s computer’s timezone is in CST. When using a calendar range and selecting “Today” token, the date selected is of a UTC “Today”. This is to be expected as the settings are laid out.

If I change the user’s dundas session timezone(dundas.context.currentSession.timeZoneId) to CST by setting the user’s timezone and then make sure dundas.context.currentSession.timeZoneId = “Central Standard Time” on the dashboard, the “Today” token still returns UTC “Today”.

I am now confused as to what controls the timezone of a token selector. I do not seem to be able to get the token to use a local timezone no matter what I do. This is crucial as users need to be able to control the dashboards in their timezone.

#2

I would have expected the same thing as what you have stated. Unfortunately we have our server set to our local time even though the server it self is in a different time zone.

@jeff is this expected behavior, is there a different setting or a defect?

1 Like
#3

As of version 6.x the resolution of tokens is currently handled on the server. Part of the reason behind this is because we want every user who does the same activity to see the same values in their dashboards/report. This being said - we 100% understand the argument for getting values in your local timezone as well as some users might desire a different experience.

If there is enough interest, we’ll likely move this way too and provide an option. There is an existing feature request open to give this option. @dante, i’ve added you to the feature request which is ref#59562 if you ever want to check the status with our support team.

#4

@jeff I believe this is a required behavior as a server can only have one timezone whereas a dundas BI instance can have multiple tenants all with different timezones that when selecting a “Today” token expect the result to be their today vs a today from another side of the planet.

#5

Working with Time is not fun :face_with_symbols_over_mouth:
Even if all your are in the same time zone.

When you have users in a lot of different time zones that are running reports on a global scale then you have to ask them what time zone do you want to be the standard for a day, other wise when the run the report they all get different numbers.

If you have a combination of user running local only reports (just one time zone) but they are all in different time zones, What do you do? You educate them, that they work for a global company in many different time zones.

2 Likes
#6

Has anyone found any workarounds? Maybe something like intercept a calendar range token and resolve it. Then if Token = “Today”, set Calendar range start and end to new Date() which will grab the user’s browser time. Or even convert it to the dundas session timezone from there. This seems like a lot of frustrating token matching unless you can resolve the tokens into actual start and end dates for all token types. I am not sure if that is possible, please let me know.

#7

Make a table or excel sheet that has all the conversions in it then make a metric set put it on the dashboard so it can be filtered to the time zone the people are in so they know what time to select to get their day or the day for that time zone they are wanting to look at.

Until Dundas does it automatically for you then it is either that or you will have to do a lot of java scripting to have it auto adjust to the persons local time, even then what if some one in one time zone is looking at some other time zone?

When a company grows to many time zones the upper management has to learn that even though every one comes to work at 8am that every one 8am is not at the same time.

Our parent company is 3 hours behind us and we all know that for us they come in at 11am.

Maybe you can make some global time tokens that are called “day for XXX time zone”.

#8

@jeff, can you please add me to ref#59562, too? This will definitely impact us. We have factories globally and all machine log timestamps roll-up in UTC. We are considering adding a “local time” column in the data lake as data is read in (based on the plant name), but this is resource intensive, as there are millions of records.

#9

absolutely @christopher.simpson

#10

@jeff
Has this been fixed or anything done to it? Running 6.0 and no matter what the timezone the TODAY is still UTC and not the actual today of the user.

#11

Hi All,

This feature request is still to be reviewed as this was submitted towards the end of our release cycle. We’re getting close to launching a very large v7 and it’s too late in the lifecycle to take new features. We will certainly be evaluating this after v7 is released.

#12

@jeff
How do we change our Server Time to something other than UTC?
we have tried a few places but nothing works

#13

Hi @alexandru.giurgiu,

The Dundas BI server is coded to use UTC so changing the server time won’t change anything for you. One thing that you could try is to create a script token so that you can resolve certain tokens in specific time zones. You can even access the users time zone if you wanted to using session.TimeZone which returns a .NET TimeZoneInfo object.

#14

Here is some documentation that will help.

https://www.dundas.com/support/learning/documentation/administration/add-a-new-group#h2-add-a-new-group

https://www.dundas.com/support/learning/documentation/create-view-content/filters/creating-custom-tokens

https://www.dundas.com/support/learning/documentation/data-metrics/writing-data-scripts-with-dundasscript#h2-7-dundas-classes

https://www.dundas.com/support/api-docs/net/#html/P_Dundas_BI_AccountServices_Session_TimeZone.htm

#15

If you cant change the time of the server or the default times sone it operates in, that kind off makes any datetime filtering pointless doesn’t it? Unless you live/work in UTC time zone OR you manually pick datetimes.

Also then what does all the different timezone settings for the users do?

#16

Hi @alexandru.giurgiu,

For almost any querying purpose we don’t take time zone into account at all and dates are simply treated as dates. If you have a datetime field in your data and you query it where the values are between x and y, this expression is simply queried at the data level and time zones have no impact whatsoever.

The only time where this becomes an issue is if you use named tokens (Today, Yesterday, Tomorrow etc.) These tokens may have different meanings in these cases and it is why you may which to create some specific time based tokens like (Today GMT, Yesterday UTC-6, etc.)

Hope this helps

#17

Open Date Boundary is also affected by UTC. And this is the default selection

#18

Hi, Jeff! I was doing some research on this topic today and would like to be added to ref #59562 as well, if you could please? I couldn’t seem to find it in the Feature Requests category. We have users in UK, Sweden and all four US time zones, so tokens for reporting are big for us as well.
Thanks!
-Ryan

#19

Certainly, Ryan. Done.