This section applies to any device, feature or application that runs in Local Time with Daylight Saving Time.
The system clocks in most computer-based systems can adjust automatically when Daylight Saving Time (DST) starts and ends, based on their time zone settings.
This section explains the effects of Daylight Saving Time adjustments in ClearSCADA and the devices or applications with which it interacts. The section uses UK Daylight Saving Time adjustments as an example, but the affects are similar in any time zone in which Daylight Saving Time adjustments are made (although the difference between Local Time and UTC may be greater).
ClearSCADA stores time values internally in UTC. On any ClearSCADA Client running in Local Time, ClearSCADA converts such time values and displays them in Local Time. (A ClearSCADA Client displays times in Local Time when being used by a user whose User Account is configured to display times in Local Time.) The ClearSCADA Client obtains its time locally from the PC on which it resides, including whether Daylight Saving Time adjustments apply to that particular time zone.
In the UK the clocks jump forward by one hour in the spring (from 01:00 GMT to 02:00 BST on the last Sunday in March). This effectively ‘loses’ that hour and so results in a day that has only 23 hours.
The affects in ClearSCADA are as follows:
- With data that is retrieved from outstations, PLCs and other devices that run in Local Time with Daylight Saving Time, no data is retrieved for the hour that is ‘lost’ when the clocks jump forward (as that hour never existed). With the data that ClearSCADA retrieves from the outstations and other devices outside of this hour, time values are converted to UTC for storage internally in the ClearSCADA database. For more information, see Outstations with Clocks that Run in Local Time with Daylight Saving Time.
- With data that is retrieved from outstations, PLCs and other devices that run in either UTC or Local Time without Daylight Saving Time, data is retrieved as usual. No time adjustments are made for Daylight Saving Time. Time values are stored internally in the ClearSCADA database in UTC format. For any ClearSCADA Client running in Local Time, ClearSCADA converts the time values from UTC to Local Time for display on that Client.
- When the clocks jump forward, the Events List on a ClearSCADA Client running in Local Time will include events up to 00:59:59.999, followed by events from 02:00.00.000 onwards.
If ClearSCADA logged events, for example, at 00:59:59.900 UTC and 01:00:00.100 UTC, these would appear to the user as being logged at 00:59:59.900 GMT and 02:00:00.100 BST.
The user would not see any events with time stamps between 01:00:00.000 to 01:59:59.999.
Conversely, in the UK the clocks jump backward by one hour in the autumn (from 02:00 BST to 01:00 GMT on the last Sunday in October). This effectively repeats that hour and so results in a day that has 25 hours.
The affects in ClearSCADA are as follows:
- The Events List on a ClearSCADA Client running in Local Time will include events up to 01:59:59.999 before the time change, followed by events that occur from 01:00.00.000 onwards after the time change
When the same Events List on a ClearSCADA Client is running in UTC rather than Local Time, events that were recorded after the time change, the UTC times mirror the GMT times (as the GMT bias is UTC+0), whereas with events that were recorded before the time change, the times differ by an hour (as BST is UTC+1).
- With data that is retrieved from outstations, PLCs and other devices that run in either UTC or Local Time without Daylight Saving Time, data is retrieved as usual.
The data’s times values are stored internally in the ClearSCADA database in UTC format.
For any ClearSCADA Client running in Local Time, ClearSCADA converts the time values from UTC to Local Time for display on that Client.
ClearSCADA raises and clears alarms as usual, processing data against the UTC time stamps in the ClearSCADA database. On any ClearSCADA Client running in Local Time, this may result in an odd sequence of events around the time that the clocks jump backward: any alarm state that persists past the clock jump might appear as cleared before it was raised. For example, the Events List might show an alarm as being raised at 01:59:00.000 BST and then cleared at 01:11:00.000 GMT (but without the time zone suffix being displayed). (On a ClearSCADA Client running in UTC, the same alarm would be shown as being raised at 00:59:00.000 UTC and then cleared at 01:11:00.000 UTC, as BST is UTC+1, whereas GMT is UTC+0.)
- With data that is retrieved from outstations, PLCs and other devices that run in Local Time with Daylight Saving Time, typically two sets of data is retrieved: one set of data for the time before the clocks jumped backward, and a second set of data for the time that was ‘repeated’ following the clock jump.
The way in which the apparent ‘duplication’ of data is handled varies per protocol. Care needs to be taken to ensure that no data is lost, due to the outstation or other device needing to store more records than usual for the period during which time is ‘repeated’.
With some protocols, the driver is able to retrieve all of an outstation’s data before changing the outstation’s clock and so is able to avoid such potential data loss.
Ideally, each outstation’s clock should be reset at exactly, or as close as possible to, the time when the actual time change occurs in that particular time zone. For example, at exactly 02:00:00.000, for the ‘repeated’ hour to run from 01:00:00.000 and 02:00:00.000.
If an outstation’s clock is reset at a later time, then the ‘repeated’ hour will run from the time that the reset occurred. So if a clock was reset at 02:15:00.000, for example, the ‘repeated’ hour would run between 01:15:00.000 and 02:15:00.000 for data retrieved from that particular outstation. For more information, see Outstations with Clocks that Run in Local Time with Daylight Saving Time.
Again, internally ClearSCADA stores the retrieved data’s time values in UTC format. The server raises and clears alarms by processing the data against the UTC time stamps in the ClearSCADA database.
An odd sequence of events might occur if an alarm was raised just before, and the alarm condition persisted until after, the clock was changed at an outstation. This is due to the fact that, during the hour that is ‘repeated’ when the clocks jump back, ClearSCADA deems any time stamped data that it receives from such an outstation to be in Daylight Saving Time.
Example:
An outstation raises an alarm on one of its points at 01:50:00.000 BST. Internally in ClearSCADA, the 01:50:00.000 BST alarm time is stored as 00:50:00.000 UTC (as BST = UTC+1).
The outstation’s clock is reset at 02:01:00.000 BST to 01:01:00.000 GMT.
The alarm clears in the outstation at 01:10:00.000 GMT.
During the hour that is ‘repeated’ when the clocks jump back, ClearSCADA continues to assume that any time stamped data that it receives from an outstation running in ‘Local Time with Daylight Saving Time’ is in Daylight Saving Time (BST in this example). Therefore, internally ClearSCADA stores the alarm clearance of 01:10:00.000 GMT as 00:10:00.000 UTC (as the time is assumed to be in BST rather than GMT and BST = UTC+1).
As the latter data is time stamped with an earlier time than the previously stored value for the point, ClearSCADA deems this to be ‘out of sequence’ data. The out of sequence events result in a non-clearing alarm until the outstation’s clock has gone past the time when the alarm was raised. Once this time has been reached, further point updates clear the alarm.
With any features, such as Schedules and Logic Programs, that are configured to run in Local Time with Daylight Saving Time, care needs to be taken to ensure that those features are not configured to trigger during the time that is ‘repeated’ or ‘lost’ when the clocks change. If the features are set to trigger during this time, this will result in the feature:
- being triggered twice for each expected occurrence during the hour that is ‘repeated’ when the clocks jump backward
- not being triggered at all during the hour that is ‘lost’ when clocks jump forward.
With Schedules and Logic Programs that run in Local Time with Daylight Saving Time and are configured to trigger on a daily basis at a time other than during the hour that is ‘lost’ or ‘repeated’, those features will trigger:
- after a 25-hour period on the day on which clocks jump backward
- after a 23-hour period on the day on which clocks jump forward.
Consider whether to associate a Schedule with a Calendar in order to trigger events as expected on the days on which the clocks change.
If any of the above scenarios are unacceptable on your system, but the devices or applications are required to run in Local Time, we suggest that those items are configured to run in Local Time without Daylight Saving Time. In countries in which Daylight Saving Time is implemented, this will result in the clocks being out by an hour for the period during which Daylight Saving Time is in force. However, there will be no apparent ‘gaps’ in data, or ‘duplicate’ data entries, for the time period that would have been ‘lost’ or ‘repeated’ had those items been configured to run in ‘Local Time with Daylight Saving Time’.