Issue
Do extended logs have accurate entries for the spring and fall time change periods?
Environment
CyberStation, all Continuum controllers, extended logs, controller logs.
Cause
What happens to extended log data during time changes?
Resolution
When the clocks are turned back, log data in the controllers will not be updated for the time interval of the change and therefore that data will not be collected by the extended logs.
When the clocks are turned forward, log data in the controllers is logged twice for the time interval of the change and therefore that data is collected twice by the extended logs.
This occurs due to the fact that each log entry in the controller does not consist of a value and a timestamp. The timestamp we see in a report is calculated by the time of the last log entry (LastLogTime) in conjunction with the configured logging interval (LogIntervalSecs). This mathematical calculation saves memory in the controllers.
Extended logging is the mechanism most sites use to store, and report on data that is in excess of the amount of data stored in a controller. The extended log engine automatically collects the controller log data before it is overwritten. An added benefit of using extended logging is that the data can be easily backed up via several strategies such as database backups and/or running extended log archiving applications. In the controllers, not only is the memory limited, but the data is stored in volatile RAM, so extended logging is a more robust and long term strategy of collecting and storing the data.
Extended logs can be set up on any of the automatic log types (LogInstantaneous, LogAverage, LogMinimum, LogMaximum).
During a period when the clock is moved forward, (for example, 2:00am Sunday March 11, 2012 on the east coast of the US), reports may display timestamps that essentially never existed (in this example 2:00am to 2:59:59am). It is recommended that these entries are simply ignored or crossed out.
The period when the clock is moved backward is more difficult, if it is critical that data be captured for the duplicated time. An example is Sunday November 4, 2012. At 2:00am on the east coast of the US the clock is set back one hour. This means that the times from 1:00am to 2:00am occur twice. However, extended log reports will only show one set of data for the reason described above. The reports will show the first 1:00am to 2:00am data; the second 1:00am to 2:00am data needs to be captured separately.
If point log data must be captured for the duplicated timeframe, additional point configuration and Plain English (PE) programming must be used to capture and timestamp the realtime data values for the duplicated timeframe. This involves creating a numeric with a manual log for each critical point which mirrors the live data value of the affected InfinityInputs, InfinityOutputs and InfinityNumerics. In addition, an InfinityDatetime point with a manual log must be created, one in each controller for each different loginterval of the points being mirrored in that controller. The PE program(s) capturing the point values will write the controller's date system variable to this InfinityDatetime at the same time it writes the live point value, thereby creating a timestamp that will be used for reporting. The last step will be writing the mirrored points and their corresponding timestamps to a file on disk and then printing and/or backing up that file for redundancy.
Click here to download a zip file containing sample dump files and a readme. This is an example of one way to accomplish the above data capture.
