<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>Hi John,</div><div><br></div><div>The times are inclusive, as you've figured out, such that that any sample occurring on the time specified will be included in output. We do not anticipate changing this logic. </div><div><br></div><div>Your request is exactly the right way to select a whole day, the problem is that the service currently only supports millisecond resolution. We will be updating the service to support microsecond resolution to match the resolution supported by the underlying miniSEED format. After which you should be able to request, for example:</div><div><br></div><div>start: 2007-03-30T00:00:00.000000</div><div>end: 2007-03-30T23:59:59.999999</div><div><br></div><div>and always get the entire day. Thanks for bringing this to light. It'll might be a week or two before we roll out an update.</div><div><br></div><div>Request time ranges using the day boundaries would work, but this is not preferable because you must deal with any overlap and it does add a bit more load for the DMC request mechanism.</div><div><br></div><div>Chad</div><div><br></div><br><div><div>On Jan 26, 2012, at 2:01 AM, John D. West wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Thanks, Doug.<div><br></div><div>That's exactly correct, in one case I'm missing a sample which should have been at 23:59.999998. I was trying to avoid crossing day boundaries because I understood that was more intensive processing on the DMC end. My process for stitching together traces can handle overlap, so the brute force method would be to just request to 00:00:01 the next day. I'd like to know if there is a more efficient way.</div>
<div><br clear="all"> -- John<br>
<br><br><div class="gmail_quote">On Thu, Jan 26, 2012 at 5:19 PM, Doug Neuhauser <span dir="ltr"><<a href="mailto:doug@seismo.berkeley.edu">doug@seismo.berkeley.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
One suggestion (which unfortunately changes the IRIS web service<br>
time specification) is for time intervals to be half-open invervals,<br>
represented in math notation as<br>
[time1, time2)<br>
This means the time interval where time t >= time1 and t < time2.<br>
<br>
I believe that all IRIS services currently defined a closed interval<br>
[time1, time2] which means the time interval where<br>
time t >= time1 and <= time2.<br>
<br>
Closed intervals make it very hard to request a series of<br>
requests whose results can be concatenated to generate a<br>
contiguous timeseries with no overlap. For day requests,<br>
2 request for:<br>
2007-03-03T00:00:00.0000 to 2007-03-04T00:00:00.0000<br>
2007-03-04T00:00:00.0000 to 2007-03-05T00:00:00.0000<br>
will contains 2 copies of a sample whose timestamp is 2007-03-04T00:00:00.0000<br>
However, if the requests are open intervals, you will never miss a sample or<br>
get a duplicate sample at a request boundary.<br>
<br>
If you are missing 1 sample at a day boundary, it could be that you are missing a<br>
sample timestamped between 59.999 and 00.000 seconds. If you are missing<br>
more than one sample, there is either a timetear (or gap) in the timeseries,<br>
or there is a problem with the IRIS web service.<br>
<br>
- Doug N<div><div class="h5"><br>
<br>
On 1/25/12 10:24 PM, John D. West wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; "><div><div class="h5">
Hi.<br>
<br>
I'm retrieving continuous data using bulkdataselect, one day at a time. A typical request line might look like "TA X16A -- BHZ 2007-03-30T00:00:00 2007-03-30T23:59:59.999"<br>
<br>
Using this method, I occasionally miss one or two samples at the day boundaries. I'm under the impression that the DMC internals make it more efficient to request on day boundaries. How do you recommend I do this to keep the data continuous and not miss samples at the day boundaries?<br>
<br>
Thanks!<br>
<br>
-- John<br>
<br>
<br></div></div>
______________________________<u></u>_________________<br>
webservices mailing list<br>
<a href="mailto:webservices@iris.washington.edu" target="_blank">webservices@iris.washington.<u></u>edu</a><br>
<a href="http://www.iris.washington.edu/mailman/listinfo/webservices" target="_blank">http://www.iris.washington.<u></u>edu/mailman/listinfo/<u></u>webservices</a><span class="HOEnZb"><font color="#888888"><br>
</font></span></blockquote><span class="HOEnZb"><font color="#888888">
<br>
<br>
-- <br>
Doug Neuhauser University of California, Berkeley<br>
<a href="mailto:doug@seismo.berkeley.edu" target="_blank">doug@seismo.berkeley.edu</a> Berkeley Seismological Laboratory<br>
Office: 510-642-0931 215 McCone Hall # 4760<br>
Fax: 510-643-5811 Berkeley, CA 94720-4760<br>
Remote: 530-752-5615 (Wed,Fri)<br>
</font></span></blockquote></div><br></div>
_______________________________________________<br>webservices mailing list<br><a href="mailto:webservices@iris.washington.edu">webservices@iris.washington.edu</a><br>http://www.iris.washington.edu/mailman/listinfo/webservices<br></blockquote></div><br></body></html>