Forgive the book I am about to write but I think others might have (or will have) this problem and find the solution useful.
I have a hub and spoke architecture with the Gateway located in the Pacific Time Zone and clients located all around the world. When viewing trend data, the times show up in the trend in the client’s time as they were logged from the client using a transaction group. This is as expected and as desired. What is not as desired is, when the chart is in “Realtime” mode, the time is in Gateway time. I want to put the trend in Manual and manipulate the time myself when the user selects “Realtime”. The OEM will also want to look at the trends but always from the Pacific Time Zone so I can’t use the {[System]Client/System/CurrentDateTime} directly to determine the Client time. My solution is to store the Client timezone in the DB and whether or not they observe Day Light Savings time. With this, I can write an expression to get the offset from Gateway to Client Site and adjust the chart time as needed. In this way, if the OEM logs in from the Pacific Time Zone, they can look at Florida, Tennessee, Arizona or Perth and the chart’s “Realtime” times will adjust to that site’s local time. My only issue is that I need to write the routine to do all this. I’m happy to do it, but wanted to check and see if there is a more elegant way to accomplish what I need to do and if someone has already done it. If not, then I will do it and share.
Granted this is an old post, but I have a similar issue that still remains unresolved (to my knowledge).
I too have hub and spoke architecture. I have servers/gateways all over the globe, and I remotely access these and run the OI as a client. If I’m using a Date Range bar, such as setting the date and time range to pull an alarm history summary, I get a mismatch between what the Date Range says I’m requesting, and the data that is provided in the summary table…the error is exactly the timezone difference between my location and the server location.
I have a workaround that I have to use, which is to change the timezone of my client before doing the Date Range operation, but this is really tedious, and means I can only get quality data from 1 timezone at a time, regardless of how many servers I’m looking at in this session.
What can I do differently, or what can be built in to Ignition, to make this more user friendly?? My issue would be resolved immediately if the Date Range and my alarm summary table were both operating on the Server’s timezone and ignore mine, not one of each.
Please help!
You can convert your times to UTC before comparing them (the date range and the data timestamp). You are probably using a string comparison that has already accounted for the timezone. You have to be careful when you do something like WHERE t_stamp > ‘{Root Container.Date Range.startDate}’
We also use a hub and spoke architecture over multiple timezones. There is no easy and efficient way to exchange data time, timezone and daylight saving between systems. So, there are basically two approaches to manage multiple timezones.
The easy one which we use
All servers running Ignition or databases are configured with UTC timezone.
We use client timezone in Ignition projects and manage conversion only in specific cases. For example, we display on the client the current client time and the selected plant current time. We need to manage the conversion only for the plant current time by storing the plants timezones in an SQL table.
The hard one
Log and transport multiple fields : datetime, timezone, daylight saving
manage conversions on calculation/input/output