Skip to main content

Time stamps and time zones

Every value in YTCC carries two times. The device time is when the event happened, as stamped by the device. The arrival time is when the value reached YTCC. When a protocol carries no time, both times are the same.

Time source​

Each value also records where its event time came from:

Time sourceMeaningEvent time used
protocol carries no timeThe protocol sends values without a time stamp.Arrival time
deviceThe device sent a valid time stamp.Device time
device time invalidThe device sent a time stamp, but it is marked invalid or failed the plausibility check below.Arrival time

These drivers can provide device time:

  • IEC 60870-5-101: CP24 and CP56 time tags. CP24 carries only minutes and milliseconds; the hour and date are taken from the arrival time.
  • IEC 60870-5-104: CP56 time tags.
  • DNP3: only when the device reports its clock as synchronised.
  • OPC UA client: the source time stamp of the value.
  • MQTT client: a time field in a JSON message, when Time pointer is set on the signal; see MQTT client.

All other drivers use the arrival time.

Time zone offset and plausibility​

Many RTUs run on local time instead of UTC. For IEC 60870-5-101 and IEC 60870-5-104 devices, the device setting time_offset_minutes gives the offset of the device clock from UTC in minutes, for example 180 for Turkish local time. YTCC uses it to convert the device time to UTC.

YTCC checks every device time against the arrival time. A device time more than 5 minutes ahead, or more than 7 days behind, is treated as invalid: the value is still used, but its event time becomes the arrival time and its time source becomes device time invalid. The 7-day margin lets an RTU send events it buffered during a long communication outage. These limits are fixed. The check applies to IEC 60870-5-101, IEC 60870-5-104 and OPC UA.

The MQTT client checks differently: a device time more than 5 seconds ahead or more than 7 days behind the arrival is dropped, not kept with the arrival time. Both limits are device settings of the MQTT driver. With the device setting Clamp future ts, a value too far ahead is kept like with the other drivers: with the arrival time and the time source device time invalid.

Values that arrive late​

A device that buffered values during an outage sends them later with their original times. Such a value is older than the last value already shown. YTCC stores it in the history with its device time, but it does not move the current value back:

  • Screens, the signal list and the server keep the newer value.
  • Alarms do not evaluate it, so no live alarm comes from an old value.
  • Scripts do not see it as a change; onChange does not run.

The MQTT client driver treats values this way: it sends a late value to the history only. A value with the same device time as the last one is applied as before.

If no newer value has arrived for more than 60 seconds, an older value is applied anyway. Without this, a device clock set back by hand would freeze the current value with good quality until the clock caught up.

Where you see the two times​

  • Signal list: the Time column, plus the Device time and Received time columns, which are hidden by default.
  • Alarm list: the Came column, plus the Device time and Arrival at SCADA columns, which are hidden by default.
  • Signal detail: Device time, Received time and Time source.

Time zones​

The browser shows all times in the time zone of the computer it runs on. The clock object on a screen has its own time zone property.

Server scripts that run on a schedule use the time zone set for the script, as an IANA name such as Europe/Istanbul. If no time zone is set, they use the local time of the server. On the day clocks move forward, a scheduled minute that falls in the skipped hour does not run. On the day clocks move back, a minute that occurs twice runs once, the first time.

Trend data exported to CSV has its time column in UTC, in ISO 8601 format. The file name uses local time.