This repository was archived by the owner on Mar 17, 2021. It is now read-only.

Description
Taurus implicitly assumes that all machines of a given distributed control system are:
- time-synchronized (using NTP or similar)
- set in the same time-zone
If the second condition is not met, we may run into some unexpected issues. Consider an scenario with 2 machines:
- M1 set to GMT where we run taurus clients
- M2 set to GMT+2 . It runs a tango DS that provides the a/b/c/d attribute
Then, if on M1 we run :
import taurus
import time
a = time.time()
b = taurus.Attribute('a/b/c/d').read(cache=False).time.totime()
print(b-a)
... we will see that the difference in times is ~7200 (2h difference between GMT+2 and GMT)
This has already manifested itself at least as the following problems:
-
If a taurus trend a/b/c/d eval:1 is run on M1, the values from a/b/c/d and eval:1 attributes are plotted with a time shift of 2h
-
If running taurus form a/b/c/d in M1 and then changing the value of the attribute, the read value may not be refreshed unless we set taurus.tauruscustomsettings.FILTER_OLD_TANGO_EVENTS=False. This is because said filter will use a local (M1) timestamp to compare with a timestamp obtained with lastval.time.totime() where lastval is the last attr value cached from a read of M2. The latter will always be "newer" (by ~7200s) and the polled attribute will be discarded.
While I do not find it terrible to force the time zone matching requirement, It may be nice to find a way of relaxing this requirement.