1 of 1 people found this helpful
The PI server is very good handling timezones, and it is a very common scenario to have data sources, servers and clients across many timezones. The PI Server stores all data internally in UTC. When data is received from a remote source, the timezone differences between UTC, the server timezone (and DST settings) and the datasource timezone are computed and thereby the data is stored using the corresponding UTC timestamp.
The same applies when reading the data, The data is shifted to the timezone of the application reading the data.
Could you give some more detail on the timezones of your components, and an example of the issue?
Thanks for your help.
The PI Server was running at UTC +1. Therefore, when I recorded some data in using an Excel Macro, as I am in the UK, it has then recorded the information as if it was an hour in advance. It has fixed the timestamp recorded against the PI tag as an hour ahead of the Timestamp I had given it. 02-jan-2016 23:58:40 has registered on the PI Server as 03-jan-2016 00:58:40.
On the same server, I have a PI2PI. The PI Server it is connected is also at UTC (UK time). I am therefore wondering if it will then offset the data from the PI Server ahead by one hour as the PI Server " was" UTC +1. I have subsequently modified the PI Server to UTC.
I am guessing when I have changed to UTC, this would cause data to be recorded amongst the hour data that was already there so to speak.
1 of 1 people found this helpful
Ont he first item, yes, the value entered from the UK (UTC) into a server in CET (UTC+1) will be shifted one hour forward. However, if you would look again at the same data from the UK, you should not see a difference. If you look at the data on the PI server in CET, you would see the difference.
The PI2PI interface should handle the timezone difference between the two servers fine.
Remember that in any case, you always look at the data through the "glasses" of the timezone of the machine you use to request the data. Data is always shown in the local timezone of the client machine.
I would suggest not to offset the data yourselves. Handling timezones, DST and the like is extremely complex, and perfecly handled by the PI system itself. So far i don't see reason why you would need to do the offset.
if the timestamp of the value you record is in a different timezone than the timezone of the client to submit the value to PI, then you would need a conversion.
Hope this helps, or otherwise, some more information on your case would help in giving some helpful directions.
you always look at the data through the "glasses" of the timezone of the machine you use to request the data
I like the analogy a lot!
PI3 Servers store time stamps in seconds since 1970 in Coordinated Universal Time (UTC). Therefore, it is important that the time and time zone be properly set on the PI Server operating system and all interface nodes and clients in your PI system.
- For most current interfaces using the extended PI API, events are sent to the server with UTC timestamps. As a result, DST and time zone differences are properly considered when storing data on the PI Server.
- PI SDK-based clients, such as PI ProcessBook 3.x and PI DataLink 3.x and later, utilize the UTC timestamps directly from the PI Server.
From what I understand, your two PI Servers are now in the same timezone. So you will see the same timestamp for data on both PI Servers compared to previously when they were one hour apart.
How do I keep a very good track of what is going on and how do I manage this issue if collecting data from multiple servers worldwide?
KB00493 - Tips for Troubleshooting DST and Other Time Related Issues : This KB explains the usage of pidiag -t *. this command can be run on both Servers and Clients. This is an effective way to see if time is correct on all the machines. It also has an interesting background section that describes how times is managed in the PI System.
In case you have questions, please come and ask us, time issues are most of the time not issues and just misunderstandings.
Please see also: