Hi,
Sorry for the delay- this setting was removed in 8 in an effort to start to reduce the multiple layers of timing definition and to get down to single sources of data.
The system timestamp only makes sense in situations where the system is scanning tags to collect values. In cases where the values are coming from the sources and being evaluated as they change, it makes sense to use the source timestamp.
So, we’ve made the logic that was previous driven by this setting more implicit. If the history is being collected “on change”, the value timestamp will be used. If the history mode is “tag group” or “periodic”, the system timestamp will be used.
I hope this helps. We’re open to refining the settings a bit more if necessary, and will be doing a little more work on tag history soon (for example, identifying and separating server-generated bad quality events from other quality events that come from the device).