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)
Christian,
Unfortunately, this approach won't work. The issue is that "Local" time refers to the local time of the computer that the code is running on. In a SaaS environment, that is the "Local" time of the OneStream App Server. OneStream App Servers are always set with their LocalTime = UTC. So, the above conversions won't help the underlying problem.
Below is the result of running your code at noon, on a machine in the US Eastern Time Zone.
At the point of time OneStream is writing or reading the data, it appears to be converting from user's true local time to UTC. However, as an end-user or developer, we don't have any tools to access what the user's true local time is. Any Business Rules we write will always return UTC as the "Local" time zone.
What technique / code / api is OneStream actually using when this data is retrieved? It must be something different that what you've mentioned above.
Thanks,
