Do tag historian queries use the client PC local time?

Had an odd complaint from an operator this morning that one of two identical clients running in different parts of the factory are showing different lines on the historical trends. Sure enough, both regular charts and sparkline charts are showing old data on one of the clients. Turns out I hadn’t connected one of the client PCs to our internal NTP server, and the time was two hours behind. Once I fixed that, everything was fine.

So my question is, is this intended behaviour? If yes, is it configurable somewhere? I’m running on 7.9.10, and I’ve used gateway time for everything so far, I didn’t even have much of reason to worry about the client time before now.

It is not so much intended as unavoidable. The local PC’s time is converted to UTC milliseconds internal to the java.util.Date class, which is then included in your queries. All of your clients need to have both the correct time and timezone or misery will ensue.

Unavoidable seems like a strong word, I would expect if I do a tag history binding that says “Realtime” and “last 30 minutes”, I would get the actual last 30 minutes the history was saved on, not current client time - 30 mins. If someone is a few timezones away and wants to check in on the production, that means he/she would have to start playing around with timezones on his or her PC.

Now that I think about it, I have a sparkline somewhere that monitors the last minute of a value that changes fairly quickly in response to another process. So if the time is out of sync by 20 or so seconds, it can confuse the operator a lot, seeing a valve open with no apparent result.

Client constructs a realtime request for data by constructing a “now” timestamp and a “now minus some period” timestamp, then asks the gateway for the data in that span. This re-uses the code in the gateway that can deliver data for any requested period of time, supporting both realtime and historical user displays. You’re asking for a special path to accommodate broken clients.

Note, there’s a special tag in the client that contains the gateway time. If you have a problem with time in your infrastructure, compare (in the client) that time vs. the client time and display a warning to your user if there’s a significant discrepancy.

If the “now” timestamp would be constructed from gateway time instead of local client time, the request logic to the gateway wouldn’t need to change.

I understand there are workarounds, but in the end they are still just that, working around an issue that, at least in my mind, shouldn’t exist. Inductive advertises Ignition as a multi-purpose platform, meaning a lot of customers use it for OEE, MES etc. Which in turn means we have non-technical office people using these clients to interface with production data, from several locations and different networks.

Which would require an extra round-trip to the gateway to obtain, or an extra gateway code path for both “now” and “now minus some period”. Extra code in Ignition to support broken clients. Which tend to only occur where 1) the client isn’t under corporate control, in which case they have no business connecting to a production system, or 2) the corporate IT department is too incompetent to enforce synchronized clocks in their domains.

In spite of jokes about IT departments, in my experience, (2) is pretty rare. (Most of the complaints about IT are due to policies that make it possible to do such enforcement.)

While I can see your argument for addressing this, I can’t see it ever being a priority. Not for an extremely tiny sliver of the user base. Especially when there are work-arounds for hard cases. The easy case is simply to require time synchronization in the client.