Timestamps Assigned to Analysis Data Offset from Actual Times

The GPS timestamps assigned to the analysis data for each detector by the logic in noise.py are incorrect. The formula there assigns timestamps assuming that the desired trigger time (trigtime) will be the timestamp of one of the samples of h(t), but this is, in general, not true. The resulting timestamps can differ from the true GPS timestamps of the interferometer data by as much as +/-1/srate; in addition to changing the definition of the reference time at which mode amplitudes are measured this can, in some cases, result in +/- 1-sample changes in the analysis data when the starting sample (the first sample with a timestamp beyond the desired start time) is extracted in likelihood.pyx.

It would be better to read in the actual timestamps from the data and carry them through all data operations to ensure they remain associated to correct strain sample.

This can make a difference in the inferred posterior; for example, using the config file here (GW150914, 220 fundamental mode plus 221 overtone, target time in H1 is 1126259462.422828) gives the blue posterior curve in the plot below; fixing the timestamps to match the actual recorded GPS times produces the orange posterior in the image below:

In this case both interferometers end up with analysis data shifted by one sample due to the offset in time stamps. The first few data points of the "onsource" segment in H1 from the buggy timestamps are

1.126259461422827959e+09 1.391203183069489925e-21
1.126259461422888994e+09 1.515840245625677881e-20
1.126259461422950029e+09 2.252559886493031912e-20

while the correct assignment of timestamps produces

1.126259461422851562e+09 1.515840164314074497e-20
1.126259461422912598e+09 2.252559959831538406e-20
1.126259461422973633e+09 2.081562205737407738e-20

which is offset by one sample. Similarly in L1 the buggy timestamps generate an onsource segment that begins with

1.126259461422827959e+09 1.839091294024837666e-20
1.126259461422888994e+09 2.063260282387470371e-20
1.126259461422950029e+09 5.068829143859443577e-20

while the correct timestamps generate an onsource segment that begins with

1.126259461422851562e+09 2.063260586148768568e-20
1.126259461422912598e+09 5.068828834728093573e-20
1.126259461422973633e+09 4.106785537325710361e-20