Scope of date objects between ignition perspective and reporting modules

[Kylan_O_Brien]

I am using a Tag Historian Query to fill a time series chart.
Using Parameters StartDate and EndDate, defaults work as expected.

I set StartDate as "fromMillis(1728534256686)"
I set EndDate as "fromMillis(1728537563688)"
and the chart displays correctly.

When I set the params of a ReportViewer as an Expression binding and set StartDate as fromMillis(1728534256686) and
EndDate as fromMillis(1728537563688)

I get a different time range.

time range in perspective:

time range in reporting Preview:

Thanks for your time

[pturmel]

That sort of problem usually means there's stringification happening somewhere, and java is trying to apply time zones, which are often different between clients and the gateway.

Share more details.

[Kylan_O_Brien]

Thank you for your time pturmel,

Some information about the gateway is provided:
Gateway version: 8.1.35 (b2023120517)
Operating System: Windows 10 | amd64
Java Version: 17.0.8+7-LTS

Both the gateway and client are installed on the same VM
It is windows 10 pro with:
Time Zone Cen. Australia Daylight Time

I am unsure of how to gather further details which may help examine the stringification.

[pturmel]

Show how you are using the parameters to get your data, and if via SQL queries, show the queries and column types.

[Kylan_O_Brien]

The time series chart is configured with range keys something like this:

I’ve hard coded the defaults as follows which I believe isolated it from my amateur designing, although there are some relics of attempts to find a way of passing a string to the Tag Historian Query.

This is the report viewer, I was using an expression binding with the fromMillis function to test the ranges because the graph was only showing a day.

For this design I’d like to be passing the params to the GraphReport view from the GraphSelect view:

The custom properties endTime and startTime are overridden by two date input boxes if the user would like.

The table (background of previous image) in the select screen is populated by this query which applies a string filter to self-managed serial numbers and recipe names.

On row click just the start and end times are calculated and passed to the custom fields.

Get serial times is just a query that returns the minimum and maximum range under unstopped conditions.

The table itself stores t_stamp as a bigint.

And it is populated when the tag running changes state.

[pturmel]

There's a lot to look at, but your default report Edate (1728537563688) doesn't match your computed endTime (1728616557492).

I'm not surprised you are getting different data.

(Consider not using millis except to catch time zone errors.)

Use a script data source in your report that logs your parameters' actual values and the first and last row from your history. Be aware that any datetime values will be stringified in the gateway timezone when logged.

(I suspect that you have a timezone problem that you are failing to work around by using long milliseconds.)

Consider using a report default start and end time that is obviously not applicable. Just make sure your report parameters are properly computed (log those, too).

Consider not making your own start/end date parameters when there are two standardized parameters there for exactly that purpose.

[Kylan_O_Brien]

Thankyou for directing me towards how to log,
I have removed the non standard parameters and these are the results.

From reports Preview:

From perspective:

Here is my logging script incase it is not accessing the StartDate/EndDate in a useful way.

[Kylan_O_Brien]

I've added an onclick event to the report to log what is being computed on the perspective side

[pturmel]

Preview has a 100-row limit from history, Perspective report viewer does not. Also show your updated tag history query that uses StartDate and EndDate. Make sure there's no use of the original Sdate and Edate anywhere.

Your history query first and last row suggest a timezone error introduced somewhere.

[Kylan_O_Brien]

Thankyou for all your help. The results are the same once the limit are removed, although I was hoping for the returned start and end time to be reflected in the timeline graph, it is likely returning the most recent data point before the timespan.

The introduction of timezone error I am unsure how to investigate, the ACDT that is being passed is correct. I can investigate the gateway and see if there is some timezone settings for the historian that are not configured correctly.