Losing data during time shift about quakemigrate HOT 2 CLOSED

Please can you run again with loglevel="debug" and send the (same) output? Presumably you didn't change the interpolate flag?

The Trace string output here (when loglevel="info") is for the trace before it is shifted (intended to highlight what's been flagged up by the off-sample test). With "debug" it will spit it out at a several more points along the pipeline and should hopefully show where it's getting rejected.

from quakemigrate.

Actually, looking more closely I can already see the issue. You're running over a day (and year) line, and the time offset is inconsistent between the two days, e.g.:

Trace
	SC.C08F.00.BH1 | 2019-12-31T23:58:53.990900Z - 2019-12-31T23:59:59.990900Z | 50.0 Hz, 3301 samples
has off-sample data. Applying +0.009100 s shift to timing.
Trace
	SC.C08F.00.BH1 | 2020-01-01T00:00:00.005900Z - 2020-01-01T00:09:17.005900Z | 50.0 Hz, 27851 samples
has off-sample data. Applying -0.005900 s shift to timing.

So once they have both been shifted, in this case there will be an overlap of one sample, and that will cause it to fail the data availability check and be rejected for onset calculation. For the few stations where this is not the case, the traces from the two days have been successfully merged so only one trace is printed out, e.g.:

Trace
	SC.M03F.00.BH1 | 2019-12-31T23:58:53.994600Z - 2019-12-31T23:59:59.994600Z | 50.0 Hz, 3301 samples
has off-sample data. Applying +0.005400 s shift to timing.
Trace
	SC.M03F.00.BH2 | 2019-12-31T23:58:53.994600Z - 2019-12-31T23:59:59.994600Z | 50.0 Hz, 3301 samples
has off-sample data. Applying +0.005400 s shift to timing.
Trace
	SC.M03F.00.BHZ | 2019-12-31T23:58:53.994600Z - 2019-12-31T23:59:59.994600Z | 50.0 Hz, 3301 samples
has off-sample data. Applying +0.005400 s shift to timing.

So it's actually just due to the data timing not being consistent over the timestep, rather than anything to do with resampling. Not something we can help with I'm afraid!

from quakemigrate.