[LEAPSECS] content of the NTP-aimed leap-seconds.list files

[Zefram]

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