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.