Daylight Savings Time - Reports Bug

Scenario.
Report data required to be reported monthly by day (a monthly report with data for each day).

Incorrect report data occurs on the date of the time change and persists for the remainder of the month.

Report setup

  1. Aggregation Mode - Doesn’t matter (Average, Duration Off, …)
  2. Sample Size - ‘Interval 24 hour’

I think if there was a Sample Size that was ‘Interval 1 day’ this bug would be eliminated.
The underlying interval algorithm could process the data by date and return the correct data. It would be much easier for Ignition to fix it once than for all customers to have to write custom scripts to look at the epoch start and end time of each day and see if it is a standard 86,400 second day, a 82,800 second ‘spring ahead’ day, or a 90,000 second ‘fall back’ day.

It took me 270 lines of python to fix this issue in one report. I just happened to notice the mistake when reviewing the data from the ignition report and this was after we had submitted the reports to the State. This put the client at risk for submitting false reports and there are probably many other Ignition users out there that are unwittingly submitting false reports to a regulatory authority because Ignition has this bug.

3 Likes