Subscribing is a smart move!
You can subscribe to this board after you log in or create your free account.
Invite a Co-worker
Send a co-worker an invite to the portal.Just enter their email address and we'll connect them to register. After joining, they will belong to the same company.
Send Invite Cancel
Link copied. Please paste this link to share this article on your social media post.
📖 Home Back
Since ClearSCADA is designed as a SCADA system capable of supporting large systems across large geographical regions, the issue if time zones needs to be understood. How does ClearSCADA handle clients in different time zones, and how are timestamps stored in the database? What happens when a client is to display data that uses different daylight saving times, particularly at the transition times between daylight saving and non-daylight saving times?
All times in the ClearSCADA database are stored in UTC (Coordinated Universal Time). The times are converted from UTC to local time when they are displayed.
The following sections describe how local times (including daylight saving times) are converted into UTC:
Outstations that use protocols that report time must use the same time zone settings as ClearSCADA . For this reason, most outstations and PLCs operate in UTC (where time is required) so that all times at the server and at the outstations and PLCs are in UTC.
We recommend that your outstations and PLCs operate in UTC. However, some drivers allow the time zone of the outstations/PLCs to be configured on a per-channel basis (defined in the Time Zone field on the Channel Form). The driver for the outstation/PLC will convert all times received from the outstation/PLC into UTC before storing the data in the ClearSCADA database. The driver will also use the Time Zone setting to set the outstation/PLC's clock (where this is supported by the device and communications protocol).
If the outstation/PLC is using UTC, the times received from the outstation/PLC will be added directly to the ClearSCADA database. If the outstation/PLC is using local time, the times it reports ClearSCADA will be converted into UTC in ClearSCADA . The conversion into UTC will take into account any daylight saving time settings that are in place.
ViewX clients can have different time zones to the server. This is possible as each ViewX client can have its own local time settings and convert times received from the server (which are sent in UTC) into local times at the client. The local time for a client (including daylight saving time) is determined by the Time Zone of the client PC (defined via the 'Date and Time' control panel applet in Windows).
When you view time data on a client, the times are shown in the local time of the client (unless the Display Times in UTC feature is enabled, see below). This means that all of the times on display are relative to the local time of the client.
To achieve this, all time values that are sent from the server to the client and from the client to the server are sent in UTC. When a client first connects with a server, it sends information about its time zone setting to the server. The server stores this information and uses it if it needs to convert any of the time values being sent to the client.
For most time values, the server sends the time values in UTC and the client converts these values into local time values itself. Similarly, the client will convert any time values it sends to the server from its own local time into UTC before sending the data. However, there are some time values that the server has to convert before it sends them to the client: time values that are within other values. For example, if the server is sending data for a status display and that status display contains a time value that is embedded within a string, the client will not be able to convert the time value as it regards the value as a string. To ensure that the client displays the embedded value in the client's local time, the server uses the local time setting information that the client sent when it first connected to the server to determine the local time of the client. It then converts the embedded time into the corresponding time at the client, before sending the string (that contains the time) to the client.
If your client PC is using daylight saving time and it makes a request to display a time value from a server that is not using daylight saving time, the time will be displayed on your client in your client's local time. If your client requests a time value from in or around the time of transition (the time when daylight saving time begins or ends), you may notice some anomalies, namely:
For example, traditionally North America changes from local standard time (LST) to local daylight time (LDT) at 02:00 am on the first Sunday in April each year. (From 2007, this will change to the second Sunday in March, but may revert to the first Sunday in April at a later date). So, at 02:00 am LDT on the first Sunday in April, time changes to 03:00 am LST. As the time has moved forward, there is a gap in the data in ClearSCADA .
If you were to look at a point's values for this time on a Trend, the Trend could appear something like this:
Trend Clock Forward at DST.JPGTrend Clock Forward at DST.JPG
Notice that at 01:00, the time jumps ahead an hour to 02:00.
Trend Clock Backward at DST.JPGTrend Clock Backward at DST.JPG
Notice that at 02:00, the time jumps back an hour to 01:00, so there are 2 01:00s shown on the Trend.
In both cases, there is no duplicate data or loss of data for the transition time as the times are in UTC (the time on the Trends' axes jumps by an hour or repeats an hour as the axes show local time, not UTC time). For example, if the second Trend shown above also had a UTC axis, the axis would look like this:
Trend Clock Change Dual Axis.JPGTrend Clock Change Dual Axis.JPG
This assumes that the local time is Eastern Daylight Time (U.S.A) and is switching to Eastern Standard Time on 30th October. As EST is 5 hours behind UTC time, the value for 00:00 (EST) on the Trend is stored in the database as a value for 05:00 (UTC).
So, when you view a time value on a ViewX client, the time value is always shown in the client's local time i.e. relative to the time zone in which the client is in (unless the Display Times in UTC feature is enabled, see below). When entering time values in ViewX, the time values you enter will be converted into UTC before they are sent to the server.
ViewX can be set to display times in UTC instead of converting them into local time. To achieve this, the Display Times in UTC option must be enabled for the User (via the Regional Settings section of the User Form and Root Group Form or via the General/Guest User section of the Tools/Options window for the Guest user.). When the Display Times in UTC setting is enabled, all times are shown and entered in UTC.
The Time Zone setting for a WebX client is similar to that of a ViewX client except that it uses both the time zone of the client that is running the web browser and the time zone of the ClearSCADA server to which it is connected.
For information that is shown in the ActiveX control (ViewXCtrl), the client's time zone is used. The ActiveX control is the rectangular display area in WebX that has scroll bars. For example, all Lists viewed in WebX use the client's time zone as Lists are displayed in the ActiveX control.
For information that is shown as raw HTML i.e. is not shown in the ActiveX control, the server's time zone is used. For example, the View pages for database items use the server's time zone as they are not shown within the ActiveX control.
When an ODBC client, for example, Crystal Reports or Excel, queries the database any times in the query or in the data returned can be in either UTC or local time. This is configured using the Local Time checkbox in the DSN setup window (see the Data Sources (ODBC) control panel applet in Windows). Local time is determined by the time zone of the client PC.
If the Local Time checkbox is ticked, the local time of the client is always used. For example, if you are using Crystal Reports on a client, and you enter a time parameter, that time parameter will always be calculated using the local time value of your client. However, if the Local Time checkbox is unticked, the time parameter will be in UTC.
Various features allow the time zone in which they operate to be configured to be UTC or local time (with or without DST). Examples of such features include:
Schedules
Logic
Historic Views
Accumulators (timed report and end of period reset)
For more information, please refer to the relevant configuration section in ClearSCADA Help, for example, for information on configuring the time zone for Historic Views, refer to the Historic Views documentation in the Server Administration Guide.
Go: Home Back
Since ClearSCADA is designed as a SCADA system capable of supporting large systems across large geographical regions, the issue if time zones needs to be understood. How does ClearSCADA handle clients in different time zones, and how are timestamps stored in the database? What happens when a client is to display data that uses different daylight saving times, particularly at the transition times between daylight saving and non-daylight saving times?
All times in the ClearSCADA database are stored in UTC (Coordinated Universal Time). The times are converted from UTC to local time when they are displayed.
The following sections describe how local times (including daylight saving times) are converted into UTC:
Time Zones for Outstations/PLCs
Outstations that use protocols that report time must use the same time zone settings as ClearSCADA . For this reason, most outstations and PLCs operate in UTC (where time is required) so that all times at the server and at the outstations and PLCs are in UTC.
We recommend that your outstations and PLCs operate in UTC. However, some drivers allow the time zone of the outstations/PLCs to be configured on a per-channel basis (defined in the Time Zone field on the Channel Form). The driver for the outstation/PLC will convert all times received from the outstation/PLC into UTC before storing the data in the ClearSCADA database. The driver will also use the Time Zone setting to set the outstation/PLC's clock (where this is supported by the device and communications protocol).
If the outstation/PLC is using UTC, the times received from the outstation/PLC will be added directly to the ClearSCADA database. If the outstation/PLC is using local time, the times it reports ClearSCADA will be converted into UTC in ClearSCADA . The conversion into UTC will take into account any daylight saving time settings that are in place.
Time Zones for ViewX Clients
ViewX clients can have different time zones to the server. This is possible as each ViewX client can have its own local time settings and convert times received from the server (which are sent in UTC) into local times at the client. The local time for a client (including daylight saving time) is determined by the Time Zone of the client PC (defined via the 'Date and Time' control panel applet in Windows).
When you view time data on a client, the times are shown in the local time of the client (unless the Display Times in UTC feature is enabled, see below). This means that all of the times on display are relative to the local time of the client.
To achieve this, all time values that are sent from the server to the client and from the client to the server are sent in UTC. When a client first connects with a server, it sends information about its time zone setting to the server. The server stores this information and uses it if it needs to convert any of the time values being sent to the client.
For most time values, the server sends the time values in UTC and the client converts these values into local time values itself. Similarly, the client will convert any time values it sends to the server from its own local time into UTC before sending the data. However, there are some time values that the server has to convert before it sends them to the client: time values that are within other values. For example, if the server is sending data for a status display and that status display contains a time value that is embedded within a string, the client will not be able to convert the time value as it regards the value as a string. To ensure that the client displays the embedded value in the client's local time, the server uses the local time setting information that the client sent when it first connected to the server to determine the local time of the client. It then converts the embedded time into the corresponding time at the client, before sending the string (that contains the time) to the client.
If your client PC is using daylight saving time and it makes a request to display a time value from a server that is not using daylight saving time, the time will be displayed on your client in your client's local time. If your client requests a time value from in or around the time of transition (the time when daylight saving time begins or ends), you may notice some anomalies, namely:
- The time of the transition is repeated (when clock goes backwards)
- The time of transition is missing (when the clock goes forwards)
For example, traditionally North America changes from local standard time (LST) to local daylight time (LDT) at 02:00 am on the first Sunday in April each year. (From 2007, this will change to the second Sunday in March, but may revert to the first Sunday in April at a later date). So, at 02:00 am LDT on the first Sunday in April, time changes to 03:00 am LST. As the time has moved forward, there is a gap in the data in ClearSCADA .
If you were to look at a point's values for this time on a Trend, the Trend could appear something like this:
Trend Clock Forward at DST.JPGTrend Clock Forward at DST.JPGNotice that at 01:00, the time jumps ahead an hour to 02:00.
Trend Clock Backward at DST.JPGTrend Clock Backward at DST.JPG
Notice that at 02:00, the time jumps back an hour to 01:00, so there are 2 01:00s shown on the Trend.
In both cases, there is no duplicate data or loss of data for the transition time as the times are in UTC (the time on the Trends' axes jumps by an hour or repeats an hour as the axes show local time, not UTC time). For example, if the second Trend shown above also had a UTC axis, the axis would look like this:
Trend Clock Change Dual Axis.JPGTrend Clock Change Dual Axis.JPG
This assumes that the local time is Eastern Daylight Time (U.S.A) and is switching to Eastern Standard Time on 30th October. As EST is 5 hours behind UTC time, the value for 00:00 (EST) on the Trend is stored in the database as a value for 05:00 (UTC).
So, when you view a time value on a ViewX client, the time value is always shown in the client's local time i.e. relative to the time zone in which the client is in (unless the Display Times in UTC feature is enabled, see below). When entering time values in ViewX, the time values you enter will be converted into UTC before they are sent to the server.
ViewX can be set to display times in UTC instead of converting them into local time. To achieve this, the Display Times in UTC option must be enabled for the User (via the Regional Settings section of the User Form and Root Group Form or via the General/Guest User section of the Tools/Options window for the Guest user.). When the Display Times in UTC setting is enabled, all times are shown and entered in UTC.
Time Zones for WebX Clients
The Time Zone setting for a WebX client is similar to that of a ViewX client except that it uses both the time zone of the client that is running the web browser and the time zone of the ClearSCADA server to which it is connected.
For information that is shown in the ActiveX control (ViewXCtrl), the client's time zone is used. The ActiveX control is the rectangular display area in WebX that has scroll bars. For example, all Lists viewed in WebX use the client's time zone as Lists are displayed in the ActiveX control.
For information that is shown as raw HTML i.e. is not shown in the ActiveX control, the server's time zone is used. For example, the View pages for database items use the server's time zone as they are not shown within the ActiveX control.
Time Zones for ODBC Clients
When an ODBC client, for example, Crystal Reports or Excel, queries the database any times in the query or in the data returned can be in either UTC or local time. This is configured using the Local Time checkbox in the DSN setup window (see the Data Sources (ODBC) control panel applet in Windows). Local time is determined by the time zone of the client PC.
If the Local Time checkbox is ticked, the local time of the client is always used. For example, if you are using Crystal Reports on a client, and you enter a time parameter, that time parameter will always be calculated using the local time value of your client. However, if the Local Time checkbox is unticked, the time parameter will be in UTC.
Time Zones for Other Features
Various features allow the time zone in which they operate to be configured to be UTC or local time (with or without DST). Examples of such features include:
Schedules
Logic
Historic Views
Accumulators (timed report and end of period reset)
For more information, please refer to the relevant configuration section in ClearSCADA Help, for example, for information on configuring the time zone for Historic Views, refer to the Historic Views documentation in the Server Administration Guide.
Go: Home Back
Author
Create your free account or log in to subscribe to the board - and gain access to more than 10,000+ support articles along with insights from experts and peers.