How to specify the time correction method?

[WayneCrawford]

Current recommendation is to set the data quality code to "D" if the time is RAW and "Q" if the time is SHIFTED. This cannot be carried over into miniSEED3, for which the data quality code is replaced by a numeric "data publication version" (0-255). Also, it has the disadvantage that, if we wish to provide both RAW and SHIFTED data, standard database formats used by data centers (i.e., Seiscomp Data Structure [SDS]) give the same filename to both. Some options are:

1. Use miniSEED3's "data publication version", with RAW data versions starting at 0 and SHIFTED data starting at 100

   • Advantages: downloads would (probably) return the highest version by default, allow user to select a version (like the current FDSN data webservice for the data quality flag). Does not break current (miniSEED2) convention.
   • Disadvantages: Non-standard use of this field. SDS would still not allow separate files for each method.

2. Use miniSEED3's "Extra Header Field", maybe even an FDSN-standard one (would have to request from FDSN)

   • Advantages: Clear specification of time correction method. Does not conflict with defined usage of a field.
   • Disadvantages: Webservices may not have a way to download "preferred" method, nor to request a specific method? Standard database file naming conventions would not allow separate files for each method.

3. Use a custom location, such as 00-D for RAW method and 00-Q for SHIFTED method

   • Advantages: Would allow separate files for each method. Easy to specify which method the user wants
   • Disadvantages: Not standard use of location code (but maybe it could become, as the dash has no standard use?). Not miniseed2-compatible (too many location characters). Would need separate channel-location definitions in StationXML

[WayneCrawford]

Option 2 seems to me the most "appropriate", if the next generation of FDSN webservices allowed selecting data based on these fields.