About timestamps on alarms at runtime

If you configure the access mode as Read (Input), the attribute’s time stamp always reflects the time stamp of the input.

If you configure the access mode as Write (Output), the time stamp provided by the value or time set request is forwarded to the output. The value is based on the attribute's existing value.

If you configure the access mode as Write, the time stamp provided by the value set request is used to update the attribute if it is not zero. Otherwise, the current time is used.

If the input source supports a time stamp, the value, time stamp and quality (VTQ) is written to the attribute. If the input source does not support a time stamp, and if a get failure, data change, or quality change occurs, the value for the attribute is time stamped with the current time.

If the quality of an output attribute is GOOD or UNCERTAIN, any value change to the attribute is forwarded to the destination attribute as it is. If the time stamp changes, the attribute's current value and new time stamp are then forwarded to the destination attribute.

The time stamp of an attribute shows the object startup time when the value is initialized after deployment. The time stamp updates to the current time if a value set request is received with a zero time stamp.

The alarm features use the attribute's time stamp, if available. If the alarm changes state, the TimeAlarmOn or TimeAlarmOff attribute updates to the time stamp of the attribute. If the attribute does not support time stamps, the TimeAlarmOn or TimeAlarmOff attribute time stamp is based on the current scan time of the hosting AppEngine. If an active alarm is disabled (which forces it to return to normal), the current time is used for the time stamp.

The history feature retrieves the value, quality, and time stamp for the attribute and then stores this data to history. If the attribute does not support a time stamp, the current scan time of the hosting AppEngine is used.