system.historian.queryRawPoints returns data outside of bounds

Zachary_Ray · March 9, 2026, 3:12pm

When using the new system.historian.queryRawPoints function, I'm gettting return data which is outside of the ending boundary. I have includeBounds set to false in the function call.

Here is the function call:

  LOGGER.info("  start     : '{}'".format(start))
  LOGGER.info("  end       : '{}'".format(end))

  query_results = system.historian.queryRawPoints(tag_paths, start, end, includeBounds=False)
  LOGGER.info("Raw query returned '{}' rows".format(len(query_results)))
  LOGGER.info("First Data Point Timestamp: '{}'".format(query_results[0][0]))
  LOGGER.info("Last Data Point Timestamp: '{}'".format(query_results[-1][0]))

Here is the console output:

11:05:26.414 [AWT-EventQueue-0] INFO Scripting-Utils.History.HistoryUtils --   start     : 'Fri Feb 27 00:00:00 EST 2026'
11:05:26.415 [AWT-EventQueue-0] INFO Scripting-Utils.History.HistoryUtils --   end       : 'Thu Mar 05 23:59:00 EST 2026'
11:05:26.542 [AWT-EventQueue-0] INFO Scripting-Utils.History.HistoryUtils -- Raw query returned '8408' rows
11:05:26.542 [AWT-EventQueue-0] INFO Scripting-Utils.History.HistoryUtils -- First Data Point Timestamp: 'Sat Feb 28 10:39:39 EST 2026'
11:05:26.543 [AWT-EventQueue-0] INFO Scripting-Utils.History.HistoryUtils -- Last Data Point Timestamp: 'Fri Mar 06 08:42:22 EST 2026'

Am I missing something / doing something wrong? I am on Ignition 8.3.5-Snapshot which I realize is meant to be for testing purposes but wanted to flag this.

apadilla · March 9, 2026, 4:14pm

Hey Zach, we actually fixed this bug pretty recently on March 2nd. Could you double check your build version and upgrade if it’s older than that?

Zachary_Ray · March 9, 2026, 8:10pm

Hey apadilla, I believe I upgraded? I'm still seeing the issue with data from outside the end boundary.

The changelog topic has versions listed like this: Nightly Changelog: 8.3.5*-b20260306

On my gateway webpage, I see I'm on version 8.3.5-SNAPSHOT (b2026030620)

I don't see any exact matches for build b2026030620. Am I on the most recent version?

Thanks

hlam · March 21, 2026, 12:53am

I’m encountering the exact same issue on 8.3.3 and 8.3.4 (nightlies aren't an option for me). The issue also exists with the Tag History binding screen when pulling data in the asStored format – this is what led me to debugging with the system.historian.queryRawPoints (it also exists with the deprecated system.tag.queryTagHistory). The Tag History binding screen was what led me to debug with the script functions.

In my scenario, I’m trying to pull real-time data while running the Core Historian for use in a SparkLine or Time Series Chart. It definitely looked like a UTC time zone conversion issue, but even with that, it didn’t make much sense, since my offset is -7 and the seed is about 6 hours off.

end = system.date.now()
start = system.date.addMinutes(end, -60)
path = ['[default]mytagpath']

print end
print start

system.historian.queryRawPoints(path, start, end)

Thu Mar 19 20:29:37 PDT 2026
Thu Mar 19 19:29:37 PDT 2026
[[Thu Mar 19 19:55:15 PDT 2026, 78.0], [Thu Mar 19 20:38:11 PDT 2026, 76.0], [Thu Mar 19 20:38:14 PDT 2026, 58.0], [Fri Mar 20 02:25:25 PDT 2026, 75.0]]

If you look at the seed being included, it’s in the future, and on top of that, it isn’t even a correct seed value (it should be 58.0) – it looks like it matches this entry instead (which is outside of the time period. [Thu Mar 19 19:25:25 PDT 2026, 75.0]. This value does have a -7 hour offset.

I also encountered a different bug when working with the aggregation tag history binding, where I’m getting 0 values between the initial time (doesn’t matter if its time or # of points) and the first valid data point. Depending on the aggregation mode, some of these zero values are actually flagged as good.

Essentially, any way of getting a live trend with the tag history binding with low sample rates gives me a bad trend.