Subtle bug in Example for Dynamic Dimensions
In the example code for the Dynamic Dimension Service there appears to be a subtle bug which will affect refresh of the dimensions. ReadDynamicDimensionInfo(...) returns DateTime.Now: ' This api m...
Forum Discussion
I don't think this is quiet the "bug" you think it is.
Based on some testing, I have found that if you pass-in DateTime.UtcNow to DynamicDimensionInfo() or DynamicDataUnitData(), OS will trigger refreshes far sooner than you expect. Using DateTime.UtcNow caused it to effectively ignore the 300 sec wait time I had configured.
It would appear DynamicDimensionInfo() or DynamicDataUnitData() DO expect you to pass in DateTime.Now, as OS's code samples show,. Presumably the functions must internally then convert the passed in Time to UTC time.
That does seem a little inconsistent when ReadDynamicDimensionContentTimestamp() ReadDynamicDataUnitContentTimestamp() are both expected to return UTC time. My personal sense is that DynamicDimensionInfo() or DynamicDataUnitData() should both be expecting UTCTime, or have an option to do so.
It could be that it assumes/sets DateTimeKind.Utc internally, just that it's not visible in the BR engine. I could see that it might appear to ignore your wait time depending upon which site of UTC you are on though
I've not looked at the code, but tbh it shouldn't really matter - as long as you keep it consistent in all calls, you should get the expected behaviour.
So I would probably recommend using utcNow everywhere.
Passing DateTime.UTCNow time into DynamicDimensionInfo() or DynamicDataUnitData() does not render expected results when in an EST time-zone when I set the refresh/expiry time at 300 seconds, whereas DateTime.Now does work correctly. Presumably the app server must be converting the supplied time to UTC time, else there could be problems where users could be coming in from around the globe.
