Define times and durations consistently throughout client
Define the initial parameters of the Series and SeriesBlock to take in time_ns to avoid precision issues, but expose the time and duration properties to return each in seconds as a float.
Also store duration_ns internally and derive duration from this similarly to keep precision.
In terms of the API, both stream and fetch can take in GPS times as floats, but internally convert them to integer nanoseconds before sending the request to the server. Docstrings are fixed so that it is more clear whether arguments/properties are in nanoseconds or in seconds. In either case, the client will use seconds throughout, but can access the nanoseconds in the {time,duration}_ns properties in the Series/SeriesBlock. Internally, the nanoseconds are used to make server requests and to derive all the second-based properties the client sees.
Fixes #15 (closed) and #16 (closed).
Merge request reports
Activity
requested review from @jameson.rollins
mentioned in merge request arrakis-server!32 (merged)
125 165 ), "data and channels dicts have different keys" 126 166 # check that the duration of all Series are consistent 127 167 for channel, data in self.data.items(): 128 duration = len(data) / self.channels[channel].sample_rate 129 if self.duration == 0: 168 duration_ns = int((len(data) * Time.s) / self.channels[channel].sample_rate) 
We could potentially run into issues in the case of non-integer sample rates, i.e. trends. We will need a better solution for the sample rate more generally, but this should not introduce new precision issues. Specifically, the order of operations was chosen to circumvent issues.
I have an idea on how to tackle the sample rate issue but is out of scope for this MR.
mentioned in commit 3df6fdf2