Steve Allen wrote: >Are there other features which would be desirable as part of a file >intended to robustly communicate the full known history of leap >seconds?
It is not particularly useful to integrate the signature into the file format. There are established mechanisms for the signing of arbitrary files, with the signature either communicated separately or wrapped up with the signed message. We should apply such mechanisms, and leave signing out of the base file format. I dislike the documentation-included approach of leap-seconds.list. That bloats the file. Documentation on how to interpret the file should be separate from the data file itself, which should not contain anything unnecessary. Any in-band hash or checksum for the detection of corruption should cover all the actual information in the file. leap-seconds.list excludes significant syntax from the hash, so there are possible corruptions that would leave a file looking well-formed, with the hash checking out OK, but imparting different information. I'd like to see explicit an explicit start date as well as end date for the file's coverage, so that as well as giving a complete-so-far leap history the file format can be used to encode shorter updates. The latter would be effectively equivalent to a Bulletin C, though with no limitation to the actual pattern of Bulletin Cs. A user application that receives multiple partial-coverage files over time should be able to assemble them into a complete-coverage file expressed in the same format. (This is another reason to avoid integrating signatures into the basic file format.) My Charlottesville paper <https://www.fysh.org/~zefram/time/prog_on_time_scales.pdf> gives a list of desiderata that includes the above, and some others, but without much rationale. I've been wondering whether the file format should be textual or binary. Possibly both should be specified: the binary format for easier machine-readability and for smaller space usage, and the textual format for human readability and editability. It would be trivially possible to convert between the two formats. Also, I wonder about the check field in a textual format: it should probably be optional, to support human editability, though highly encouraged for published files. I imagine the body of the textual format looking something like this: 1972-01-01 1972-06-30 +10 1972-07-01 1972-12-31 +11 1973-01-01 1973-12-31 +12 ... 2009-01-01 2012-06-30 +34 2012-07-01 2015-06-30 +35 2015-07-01 2015-12-31 +36 That is, tuples of start date, end date, TAI-UTC difference. Leap events are implied by different TAI-UTC differences on consecutive days. End date of 2015-12-31 above doesn't imply that there'll be a leap on that day, just that it's the end of the period for which we know TAI-UTC = 36 s. Dates given in Gregorian calendar and ISO 8601 for human readability (unlike leap-seconds.list, which despite being textual is effectively impossible for an unaided human to understand). Anyone interested in me working up a full spec? -zefram _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
