queryTagHistory and DST

How does Ignition handle requesting data via queryTagHistory that spans a transition into or out of daylight savings time? I'm not seeing one hour less into DST and an extra hour out of DST, as I would expect.

Ignition datetime values are really instances of java.util.Date, which are UTC under the hood. Always. They display in a local time zone when printed (stringified), and are constructed in local time zones when parsed. At all other times, they are zone-less. You should recheck how you are generating your start/end boundaries.

I'm specifying startDate and endDate with Ignition DateTime objects.

Of course you are, because that's what the function requires. How are you getting those Datetime objects? Show your code.

# ./Controls/Start & ./Controls/End = Perspective DateTime Inputs

# props.custom.start (expr) = 
# if({this.custom.historical}, {./Controls/Start.props.value}, addMinutes({this.custom.end}, {this.custom.minutes}*-1))


props = self.custom
props.wait = True
query_tags = []

for tag in props.tags:
    query_tags.append(str(tag.path))

data = system.tag.queryTagHistory(
    paths = query_tags,
    startDate = props.start,
    endDate = props.end,
    columnNames = query_tags,
    returnSize = props.returnSize,
    intervalSeconds = props.aggregation,
    aggregationMode = props.aggregationMode,
    noInterpolation = False,
    ignoreBadQuality = True,
    validateSCExec = False)

self.refreshLayout()

props.data = data
props.wait = False

Ok, you have custom datetime properties. How are you writing to those before the history query runs?

Some other script? Datetime input components?

Yes. See the top comment in the above code for reference. I'm using DateTime Input components. The value is being read from a custom property via expression. Depending on the mode, I'm either taking the value directly or using the end time and deducting a specified number of minutes using the addMinutes expression function.

What does your session timezone property show? (That is what your datetime inputs will use.) The date arithmetic for non-historical will act on the UTC datetime objects, so I hope you don't expect that to respect your time zones.

That's It. It does seem the perspective project was changed to UTC at some point. I understand now, thank you. I should have checked there first. When the zone is set correctly, it does, in fact, return the extra hour when transitioning from PDT to PST.

1 Like