FDSN beta service waveforms do not begin and end at requested times

[calum-chamberlain]

This actually holds true for the current fdsn service as well. The below example uses the obspy fdsn client, which appears to pass arguments properly to urls:

from obspy.clients.fdsn import Client
from obspy import UTCDateTime

client = Client('http://beta-service.geonet.org.nz')
st = client.get_waveforms(
    network='NZ', station='CNGZ', location='*', channel='EHZ',
    starttime=UTCDateTime('2019-09-04T04:00:0:0.000000'), 
    endtime=UTCDateTime('2019-09-04T05:00:00.000000'))
print(st)
1 Trace(s) in Stream:
NZ.CNGZ.10.EHZ | 2016-09-04T04:00:01.308441Z - 2016-09-04T04:59:56.868441Z | 100.0 Hz, 359557 samples

While this queries the database accurately (generating the url: http://beta-service.geonet.org.nz/fdsnws/dataselect/1/query?channel=EHZ&station=CNGZ&starttime=2016-09-04T04%3A00%3A00.000000&location=%2A&endtime=2016-09-04T05%3A00%3A00.000000&network=NZ%27

The returned data do not start at the requested start-time, nor end at the requested end-time.

It looks like the FDSN spec states that data can start at the start-time or after (and vice-versa for end-time), but, other services provide data closer to that expected. It would be really nice if the GeoNet FDSN did the same.

I say that this holds for the current FDSN, but that isn't quite true: a similar request using the current FDSN service yields the following data:

1 Trace(s) in Stream:
NZ.CNGZ.10.EHZ | 2016-09-04T03:59:54.568443Z - 2016-09-04T05:00:02.408443Z | 100.0 Hz, 360785 samples

In this case, the data do not appear to meet the FDSN specs, both starting before the given time, and ending after the end-time.

Further to this - a more general question, why do GeoNet data not have samples at zero-millisecond times (e.g. the closest sample to the given start-time is actually at 2016-09-04T03:59:59.998443). Is this an accumulated leap-second thing?

[nbalfour]

I have moved this ticket to GeoNet/fdsn#78