Thread: Next generation miniSEED - 2016-3-30 straw man change proposal 7 - Change start time to custom structure

Two issues that should be pointed out this this change. The first is
that a "leap second occurs IN this record" is required in either case,
and positive/negative direction is needed. A record that overlaps a
leap second is different from a record where the start time is IN a
leap second. Consider a 1sps record containing 11 samples with a start
time of 23:59:50 on 31 Dec. The starttime is not a leap second in
either case, but the last sample could occur either at 00:00:00 on 1
Jan or at 23:59:60 on 31 Dec. Allowing the seconds field to be 60 is
insufficient in this case and so some extra information beyond the
start time is needed even in the case of the BTime structure.

The second comment is that users do not interact directly with
miniseed currently, and will not do so in the future. There will be
software libraries in each of the popular languages that do this for
them, and those libraries will convert times into the languages
default representation. A BTime might be a little less confusing for
the developer, but the user is going to use a value in software that
looks a lot like the IEEE format when they initiate any processing.
Having the file format doesn't make this problem go away or really
even make it less likely. What would help is if libraries were created
with functions such as getTimeOfSample(27) or
timeDifferenceBetweenSamples(sample1, sample2) so that the library
does the math correctly taking into account the leap seconds.

I was originally somewhat against the IEEE format, but the more I
think about it, the less I think it matters. Math with time is hard
and the file format is not the right place to protect users against
doing wrong subtraction across leap seconds. The software that uses
the file format is the right place for that.

thanks
Philip

On Thu, Aug 11, 2016 at 3:49 PM, Chad Trabant <chad<at>iris.washington.edu> wrote:

Hi all,

Change proposal #7 to the 2016-3-30 straw man (iteration 1) is attached:
Change start time to custom structure.

Please use this thread to provide your feedback on this proposal by
Wednesday August 24th.

thanks,
Chad





----------------------
Posted to multiple topics:
FDSN Working Group II
(http://www.fdsn.org/message-center/topic/fdsn-wg2-data/)
FDSN Working Group III
(http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
Update subscription preferences at http://www.fdsn.org/account/profile/

I agree very strongly with Doug Neuhauser’s comments with regard to use of
64-bit “unix” time.



In addition to the specific issues Doug has raised with regard to handling
of leap seconds, there are general concerns.


1. Unix time is referential; without a qualified conversion, the time value
per se is useless. The POSIX standard is deliberately non-committal in
defining how it should be interpreted, stating:



“It is sufficient to require that applications be allowed to treat this time
as if it represented the number of seconds between the referenced time and
the Epoch. It is the responsibility of the vendor of the system, and the
administrator of the system, to ensure that this value represents the number
of seconds between the referenced time and the Epoch as closely as necessary
for the application being run on that system.” (underline mine)



The proposed straw-man approach would presumably attempt to represent UTC
with a (modified) Unix time that, when conversion to a broken-down Gregorian
time/date, the correct UTC date/time is returned. This approach is subject
to errors of interpretation, requiring, in effect, that each time tag must
be reconstructed for valid interpretation.

The approach is convenient for data center management, but forces onto the
user the valid development and interpretation of the time tag and leap
second management.
In contrast, there is no ambiguity in the archive, and the content is
essentially self-contained and self-documenting as to the presence of a leap
second using the broken-down time representation.



2. A monolithic 64-bit tag is opaque to inspection. It is prone to subtle
errors in construction and manipulation, for example, loss of 8 bits or 16
bits, with no apparent symptom.





The use of a 64-bit tag inappropriately confuses processing convenience with
archival integrity.

An archival representation should be as free as possible from ambiguous, or
outright inaccurate (as in the case of leap-second handling using Unix
time), representations.
A broken-down UTC time tag, as in the present format (with additional
microsecond resolution), serves as an identifiable, unambiguous stand-alone
time mark in each archived data record.





Joseph Steim






From: Chad Trabant [chad<at>iris.washington.edu]
Sent: Thursday, August 11, 2016 3:48 PM
To: Tim Ahern <tim<at>iris.washington.edu>; Bob Hutt <Hutt<at>asl.cr.usgs.gov>;
Bruce Beaudoin <bruce<at>passcal.nmt.edu>; Pete Davis
<pdavis<at>epicenter.ucsd.edu>; Kent Anderson <kent<at>iris.edu>; Bob Woodward
<woodward<at>iris.edu>; Katrin Hafner <hafner<at>iris.edu>; Justin Sweet
<jrsweet<at>uw.edu>; Brent.Evers<at>iris.edu; David Wilson <dwilson<at>usgs.gov>;
Mathias Franke <mathias.franke<at>kmi.com>; Ogie Kuraica <ogie<at>kmi.com>; Neil
Spriggs <NeilSpriggs<at>nanometrics.ca>; Angel Rodriguez
<angel<at>volcanbaru.com>; Leonid Zimakov <L.Zimakov<at>reftek.com>; Edelvays
Spassov <ens<at>kmi.com>; Branden Christensen
<branden.christensen<at>osop.com.pa>; Dieter Stoll
<dstoll<at>lennartz-electronic.de>; Seiji Tsuboi <tsuboi<at>jamstec.go.jp>; Jara
Salvador, Jose Antonio <JoseAntonio.Jara<at>icgc.cat>; David Easton
<davideaston<at>nanometrics.ca>; timparker<at>nanometrics.ca; John Clinton
<jclinton<at>sed.ethz.ch>; Vallee Martin <vallee<at>ipgp.fr>; Constantin Ionescu
<viorel<at>info.ro>; Marmureanu.Alexandru<at>dst.units.it; Bogdan Grecu
<bgrecu<at>infp.ro>; Cristian Neagoe <cristian.neagoe<at>infp.ro>; Helle Pedersen
<Helle.Pedersen<at>ujf-grenoble.fr>; Catherine Pequegnat
<catherine.pequegnat<at>obs.ujf-grenoble.fr>; Pierre Volcke
<pierre.volcke<at>obs.ujf-grenoble.fr>; Angelo Strollo
<strollo<at>gfz-potsdam.de>; Sébastien Judenherc
<Sebastien.Judenherc<at>fedd-scientific.com>; Tony Russell
<tony.russell<at>kenda.co.uk>; Robert Leugoud <rleugoud<at>eentec.com>; Jiang Li
<lijiang01<at>geodevice.cn>; Lani Oncescu <lani<at>kmi.com>; Shawn Goessen
<support<at>guralp.com>; Dennis Pumphrey <dp<at>kmi.com>; Suzan Kowalski
<suzankowalski<at>nanometrics.ca>; Bruce Townsend
<brucetownsend<at>nanometrics.ca>; Joseph Steim <steim<at>quanterra.com>; Ian
Billings <reftek_support<at>trimble.com>; Claudio Parma <c.parma<at>solgeo.it>
Cc: fdsn Group II <fdsn-wg2-data<at>lists.fdsn.org>; FDSN Working Group III
<fdsn-wg3-products<at>lists.fdsn.org>
Subject: Next generation miniSEED - 2016-3-30 straw man change proposal 7 -
Change start time to custom structure





Hi all,



Change proposal #7 to the 2016-3-30 straw man (iteration 1) is attached:
Change start time to custom structure.



Please use this thread to provide your feedback on this proposal by
Wednesday August 24th.



thanks,

Chad