This is good advice. Iâd also like to add to remember to always be very careful with dates in JS. Unfortunately JS doesnât have good date support, especially with time-zones, and it can be rather confusing. To make it worse, by definition all dates are actually ranges because they lack granularity - for example if you want to see âJan 1â, itâs technically âJan 1 midnight to Jan 1 11:59:59â, so memberTime in this example will yield âJan 1 midnightâ, and the upperBoundaryTime would contain the âJan 1 11:59:59â (assuming you wanted the day level). The only exception being stored procedure parameters which expect an explicit date/time slice (SingleDateTimeValue usually).
To further make this confusing, if thatâs even possible, crafting a date in JS (new Date()
) yields a local time which, if sent to the server directly, would suffer date-shifting. This is even more complex because not every browser necessarily offsets the date when created. Itâs a mess.
In any case, in your particular example youâre referencing the property dundas.data.MemberValue.memberTime. This date will be in UTC (on purpose), and it is safe to send back to the server for filtering. However, often people will use the dundas.data.TimeHierarchyMember instead (or just HierarchyMember) as a result of a getMembers call, or just processing the dataResult on a particular DV. When a hierarchy member is used (not memberValue), the memberTime and upperBoundaryTime properties are actually local. This is useful for displaying in a DV, but useless for sending to the server since your times will all be shifted. As such, itâs important to always call loadMemberValue before sending it to the server which will automatically convert the local dates to UTC.
This is also (and 1 of a few reasons) why we highly recommend using the Calendar Control (over the date/time control), and working with Time Dimensions and hierarchy members as much as possible instead of âactualâ dates. I realize this may seem like more work at first, but the pay-off is that you donât need to deal with any UTC/local offsetting or bad JS date handling, and never need to worry about time dimension mapping (fiscal or otherwise) as well as caption formatting. Itâs a very big benefit, albeit with some up-front cost.
Lastly, in an upcoming version of Dundas BI next year youâll have a much easier time working with tokens in the UI as weâve implemented the ability to âresolveâ tokens to their real values.