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.