12-23-2022 06:33 AM - last edited on 02-07-2023 12:50 PM by JackLacava
We're working on a solution, where users can enter and view a date through a Cube View using the Cell Type Date. The challenge is how OneStream handles date's (datetime) with time-zones. When a date is saved to the backend, it's converted to UTC time-zone. The Date component in the Cube View is also Time-Zone aware, so that it uses the local time of the user, to convert back from the backend UTC to local-time. The challenge with this is 2 fold:
1) Assuming we would calculate a rent for a given period. The user, based in CET time-zone, enters 2022-1-15 using the Gridview. This date is converted to 2022-1-14 as UTC (2022-1-14 23:00:00). Using a Custom Calculate method to calculate the rent from start (2022-1-15), now adds one day more, as the server time is UTC. (don't mention Daylight Saving Zone)
2) If another user, based in US Central, is reviewing data in the same Grid View (and same POV), this user will see a wrong date, as the server UTC date, is converted to this user's local time
Is there a way to specify in the Cube View, that when using the Date/DateTime picker, that the component should ignore time-zones? Or are there other usable solutions for this issue?
12-24-2022 10:51 AM
I don't see this behaviour in my version (7.2.2). I created two users with different cultures (US and Japanese). When they manipulate a cubeview in Data Explorer, pointing to a NonFinancial account in V#YTD, with a column with Cell Type set to Date or Date Time, whichever value they set will get saved in the database as it is - so both users see exactly the same value, not going through any UTC-related mangling.
As far as I can see, OneStream is simply taking the datetime object and saving the value of its .Ticks method. If you want to manipulate it for some reason (e.g. intercepting it into some event handler), you can reconstruct the object:
Dim myDate as new Date(yourDataCellObject.CellAmount)
12-26-2022 05:25 AM
I don't think the culture setting in OneStream affects anything related to this. Isn't culture more on language shown + formatting of numbers etc? Try to change the time-zone on your computer, restart the OneStream Client and check if the time is still the same in the Cube-view if you're on US and Japanese time-zone
Though, I have testet on 7.0 and 7.1. Both versions saves dates to UTC and converts to users local time-zone defined by the computer configuration. Will test if 7.2 includes a bugfix.
12-26-2022 06:21 AM
Just to follow up - now tried on 7.2.2. Still same issue. This is Cube View on Time-Zone UTC-6
Changing the Time-Zone to UTC+1, the same Cube View with same POV now shows:
12-26-2022 08:27 AM - edited 12-26-2022 08:31 AM
This isn’t a bug, it is expected behavior.
You need to take the time zone of the reporting entity in consideration when you are calculating the rent with a custom calc. VB.net has a set of function to help you handling time zones.
Dim myTimeZone As TimeZone = TimeZone.CurrentTimeZone ' convert DateTime.Now to local and universal time. Dim local As DateTime = myTimeZone.ToLocalTime(DateTime.Now) Dim universal As DateTime = myTimeZone.ToUniversalTime(DateTime.Now)
12-26-2022 10:20 AM
On the backend, I more or less can make a workaround, converting the UTC stored values to a specific target Time Zone. The biggest issue is the fact, that 2 users, reporting/reviewing/calculating values on the same entity, will eventually look differently at the same date. A user in Germany will input a date, which is converted to a UTC value (because of the time-zone of the server backend). His colleague in US reviewing data, will see the date in a different time-zone, as the Cube View converts the backend UTC value, to his local timezone. And from a user perspective, this could look like 1 day in difference, if only looking at the date value, not including time. So a UTC+1 time of 2022-01-01 (00:00) becomes 2021-12-31, from a UI perspective. So my point is more, that OS, in this case, should ignore the time-zone information. And that's where I'm trying to find a solution.
01-09-2023 08:30 AM
we are also facing the same issue with the date fields in the data entry forms.
OneStream has confirmed that this a potential bug in the product and they wokring on it with high priority.
01-09-2023 09:18 AM
Thanks for sharing - can I ask when you did report this? Cheers
01-09-2023 09:49 AM
we have reported this to oneStream last week.