Determine where clock_zero request fits into Framework #42
Description
Gary Egbert would like to use mth5 and aurora for the analysis of several hundred stations. He would like the ability to save (or at least rapidly reproduce) FC Files. He uses the idea of a reference time with respect to which his Fourier transform windows are defined. This allows arbitrary "FC Files" to be used with one another, guaranteeing that the phases of harmonic waves w.r.t. each window are synchronized.
A clock-zero seems to be arbitrary. It is also not relevant to processing without the definition of a "window advance" = (window_length - window_overlap). It is thus a quantity that is associated with a spectral dataset defined by two parameters which gives rise to an sequence W of "window_edge_times".
Within the context of a data analysis project using this concept would make FC files more reusable, but N.B. that we do not currently support FC files!
In any case, within an analysis context a clock_zero, together with a window advance can be used to tweak the metadata by insisting that any "runs" in the dataset have start times drawn from the set W
Question: It seem that the clock-zero is not critical for SS TF processing. For RR it is also not important as long as all blocks being processed together share a common start time. The issue comes about when you have a bunch of FC data structures already made and you want to mix and match them for processing -- in that case, having a common clock-zero (or W) guarantees that you are not introducing artefacts or errors in the SDM.
This issue relates to STFTCollection.