nanosecond resolution?

[chad-earthscope]

No description provided.

[crotwell]

If we have UInt32, it fits and we are covered if sub-microsecond data ever shows up. I don't see any obvious downside, other than time being recorded more accurately then it is actually known.

[chad-earthscope]

The 20170622 draft includes a record start time with microsecond precision. I'm dubious that nanosecond resolution is needed for a time series format focussed on seismology, here is what I've written earlier:

So the question is why nanoseconds. Considering extremes for geophysical data, at 10 kHz sampling the signal that can be represented is 200 microsecond period (5 kHz signal). With microsecond time resolution, a time stamp is 1/200th of that period. I wouldn't be totally opposed to nanoseconds but some justification beyond because we can would be nice.

But if we wanted to change it, this major transition would be a good time.

As pointed out, this doesn't cost any more space, the same uint32_t can hold nanoseconds. So it doesn't matter for the format structure itself.

I don't see any obvious downside, other than time being recorded more accurately then it is actually known.

In addition, a few others:

• the display of time stamps for reporting data times (availability, coverage, etc.) all become nanosecond or is rounded?

• FDSN data selection criteria (web service parameters) are expanded to allow nanosecond resolution?

• the ripple of software changes needed to support this. Of course a major version change is more of a wave, so this ripple is a (really important) change within many changes. I'm pretty sure I can modify libmseed to change it's internal time base, which will cause more ripples for programs that use the library. Postgres timestamp type conveniently stores microseconds cleanly, not so for nanoseconds; so maybe that becomes an operational decision to only store microseconds. etc.

I'm guessing there are many small areas like those that would need touching or consideration to support nanoseconds.

Maybe the practical approach, if nanoseconds are included, is to just keep supporting the SEED ecosystem at microsecond level.

Thoughts?

[kaestli]

As stated elsewhere: we have people here locating ruptures in 5 cm rock samples, with sampling frequencies of (currently) 20 MHz. I would not be surprised if in other fields than seismology, ever higher sampling rates are not uncommon. I think it does not pay off to maintain different storage standards, different software ecosystems etc. just because somebody, because this allows parts of the time series community to save two bytes in time resolution.

[chad-earthscope]

As stated elsewhere: we have people here locating ruptures in 5 cm rock samples, with sampling frequencies of (currently) 20 MHz.

Fair enough.

I would not be surprised if in other fields than seismology, ever higher sampling rates are not uncommon.

Well, yes, and they are not the fields we are making a format for.

I think it does not pay off to maintain different storage standards, different software ecosystems etc. just because somebody, because this allows parts of the time series community to save two bytes in time resolution.

As written above, it does not even cost more bytes. The cost, as it were, is downstream of the format, the ecosystem around the format.

Laboratory geophysics seems like a target we may want to try to support, even though they may not have much interest in miniSEED, eventually that kind of data may need to be handled by an FDSN data center. Good, concrete reason to consider expanding the resolution.