What is the recommendation regarding observing daylight savings time on the PI Server?
Archive timestamps in the PI Data Archive are stored as number of seconds past January 1, 1970. It uses Coordinated Universal Time (UTC), meaning that a time correction is applied to normalize the time zone to Greenwich Mean Time (GMT). Thus the server is not impacted by daylight savings time.
When PI clients pass archive data requests to the PI Data Archive, the server will translate the local PI time to UTC time since this is what is stored. The server will then perform the translation based on its own timezone and DST setting. Once the PI 3 server calculates the UTC time, it can retrieve the appropriate data from the archive. Then it translates the UTC PI time back into the local PI time and passes this back to the client.
To ensure that the correct UTC time is stored on the PI Data Archive, make sure you have the updated localhost.tz file applied on your system (they can be downloaded, or customized). You will also want to ensure that you have the daylight savings time box check in the Windows clock setting if you indeed want the server to observe daylight savings time.
For more information, you can refer to the following documents:
FYI, I have moved this question to All Things PI > PI Server for continued discussion. Please let us know if you have any specific questions. Thanks.
PI stores values in UTC. So there is no problem with DST. Time is presentet in the corresponding timesone on the client who requests data. The same (revrse: converting local tinme into UTC) happens while storing data into PI.
Great info. We have had some questions recently regarding how our PI Server is setup. I know all the values are stored in UTC and the values are not lost say we jump an hour. The PI Server does however look like it observes daylight savings time. Is it recommended that its set to observe it or match up with the source DCS/Scada systems?
The PI Server and Interface time zones do not have to be the same. As long as the interface is set up with the correct time, time zone and DST, the time can be converted correctly into UTC when stored in the PI Data Archive. This is only an abbreviated explanation though; I encourage you to check out KB 649OSI8 (link) for detailed information about the details and caveats of time settings on interface nodes and data sources. And let us know if you have any further questions!
Do you know of a way to get the data in its raw format without having DST observed in it? The need is for reporting that our business is trying to do with tools like excel. How do they query the archives and see the data as if they were not in a time zone that observes daylight savings?
Most PI clients allow you to pick whether you are using PI Server time or local client time. This means that if the client is configured to use client time and the user does not observe data light savings time you should be fine. If the users do observe DST (based on computer clock), you can override the computer clock settings using localhost.tz on the client computer to make sure the data is not viewed in DST.
Perhaps you can let us know how you would like to extract out the PI Data and we could give you more specific advice on how to extract out the UTC time. If you are using Excel for reporting, then PI Datalink sounds like a good option.
We some reports that do hourly, daily and weekly averages but over that one day and week where the time change happens the "missing" hour causes issues to the report. When you use datalink for example it will exclude the one hour if the client machine observes DST which is almost always the case. If you set it to use UTC time you get that gap filled but the times are not in the local machine time. How would you handle this case?
Well, in UTC there is no "gap" And in local time there is also no gap - it is just a matter of the report and if it is aware of DST or not. The report should be able to identify the two dst events and handle it correct. It belongs to the responsibility of the creator of such a report that he or she enables the correct DST handling.
Retrieving data ...