Scheduled Reports offset due to daylight savings

Hello, I have came into a weird issue due to daylight savings, In short I have a scheduled report that gets sent at 12 am everyday and shows the prior data for a 7 day period. Before Daylight savings I had no issue with this report schedule. After Daylight savings I’ve been having issues where it seems the data will try to grab info at 1 am for dates past daylight savings time. Does anyone know if there’s a fix to this?


I did find this, but i do not have the luxury of restarting my gateway/server rn due to the site in constant operation

It looks like the data is coming from the tag historian with an interval of 1440 minutes and a start time set to 00:00. Unfortunately, that won’t work twice a year if you are in a DST time zone.

I think its more work than its worth, but you could use script query to go through your history query and twice a year alter your time stamps for that one run of the report. You would just be faking it out for DST changes. You would also need to alter you start and end parameters to be accurate.

I have my query for my tag historian set to 24 hours, I wish I could set it to 1 day I would think that could resolve the issue. This is just wishful thinking though.

At the moment I am going to alter my timestamps so it will work for this time period I am thinking by the 21st the Issue will resolve itself and I will be able to set my parameters back to the original format.

Sadly neither of these seems like end all be all solutions.

I’m pretty sure that system.date.addDays() will give you a 23 hour or 25 hour interval when crossing a time change.

It seems system.date.adddays is a scripting feature. I am using tag historian query with a interval of 24 hours query my data. Do you believe writing script that query my tag history using system.date.adddays() could work better?
I haven’t tried querying data using scripting yet. I will have to research a bit to accomplish this.

I assumed my issue is related to my start and end date parameters which is expression based. I have used dateArithmetic(now(0), -1, ‘day’) and addDays(now(0), -1). to see if this helps with no progress.

system.tag.queryTagHistory - Ignition User Manual 8.1 - Ignition Documentation (inductiveautomation.com)

I’ve been reading the set up of how to query tag history but it seems I run into the same issue i have currently with the IntervalHours, Intervalminutes, and intervalseconds. Since those values are looking for a integer in either of those 3 criteria to query my data over a 24 hour/1 day period.

When setting up scripted query to reports is there another way to get tag historian data? I’m not seeing many options online.

You can have a script data source in addition to your tag history data source.
This is a basic example, you would need to check which timestamps need adjustment.

import java.util.Date
queryData = data['tag_history'].getCoreResults()
arr = []

for row in range(queryData.getRowCount()):
	oldTime = queryData.getValueAt(row, 't_stamp')
	newTime = system.date.addMinutes(oldTime, -60)
	arr.append(newTime)
data['tag_history'] = system.dataset.addColumn(queryData, arr, 'newTime', java.util.Date)

I think i am missing something obvious here with how system.date.add??? works. If i add -1 hours it subtracts 1 hour but also ignores the DST change, but if use system.date.addSeconds or system.date.addMillis it does the date math but does not ignore the DST change. I could not figure it out, hopefully someone can enlighten me.

This is the result with adding -60 minutes (same results with -1 hours).
image

And with adding -1 seconds.
image

I'm having this exact same issue. Is there anyway to get an aggregation mode by day (instead of hour). I would hope something like that would then handle the 23 hour day in March and the 25 hour day in November.

Or is there other work arounds people have? I would think a lot of people would have run across this issue and had to deal with it. It's surprising it isn't easier to deal with.

1 Like

To whom it may concern, a proposed workaround his presented here:

https://forum.inductiveautomation.com/t/report-tag-historian-query-aggregation-by-day/69948