Skip to content
This repository has been archived by the owner on Mar 17, 2021. It is now read-only.

problems with unmatching timezones #1167

Open
cpascual opened this issue Dec 15, 2020 · 0 comments
Open

problems with unmatching timezones #1167

cpascual opened this issue Dec 15, 2020 · 0 comments

Comments

@cpascual
Copy link
Member

cpascual commented Dec 15, 2020

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant