I have a graph displaying the tag history on the /run/Production Rate (hour) that has been working great… until now. I have just installed Ignition on a machine in Korea, and the dates on the graph are SERVER time, not client time. This causes alot of confusion for the Koreans (14 hour difference).
I wrote a script that runs through the dataset before binding to the graph and subtracts a configured number of hours from the date, but it seems a bit slow.
Has anyone else encountered this, and if so, have you come up with a workaround? I don’t see anything in the binding of the Historical Tag function that specifies to return the client date/time.
I think the solution might be as simple as changing the “Timezone Behavior” setting for the project. It’s set in the designer, by going to Configuration>Properties>Client/General. It appears to be set to “Gateway Timezone” by default. Try changing it to “Client Timezone” and see if that helps.
It gets very confusing when we start talking about timezones. Let’s use some examples so we can make sure we know what we’re talking about.
Let’s say data is stored on the server, which is in timezone “A”. In Timezone “A”, the data is as follows:
Time | Value
8:00 | 14.5
8:05 | 16.8
Now let’s think about a client in timezone “B” which is +4 from “A”
If the client is set to use the Gateway’s timezone, the data should look identical. If the client is set to use the client’s timezone, the data will look like this:
Time | Value
12:00 | 14.5
12:05 | 16.8
Can you explain what you want to happen that isn’t covered by the above scenario?
So, it seems there at least “were” two issues here.
I made a mistake on the first one, and I realize that now. You are exactly correct in your explanation of the scenario below. When I last looked at this, I had changed the timezone on the client while the project was open on the client, and did not restart it. Restarting the project / client caused the graph to properly display the time. See attachment. Time should be 4:00am, 3:00pm server time as it is a realtime historical tag graph.
However, the other issue is that the downtime reasons do not adjust this date/time properly. In addition, the returned date column is not a complete date, so it is impossible to massage the date before displaying it, perhaps in a standard table. That component has a few features that are not in the column anyway.
I believe you are working on this, so I will just be quiet for a bit until I see the next release. Pete Low said it was coming out soon.
