[LEAPSECS] Time math libraries, UTC to TAI

[Zefram]

Tom Van Baak wrote:
>Collecting device timestamps may need to be convertible to TAI.

Does this conversion have to be done at the time of submission to the
ledger?  Since the ledger supplies a more reliable timestamp itself,
it may not be necessary for the collector timestamp to be universally
readable.  That could potentially sidestep difficulties around not knowing
how a device clock behaves around a leap second.  Retrospectively acquired
knowledge of the time scale the device tries to tick can be applied in
the same way as retrospective knowledge of the device's accuracy.

However, it shouldn't be too great a hardship to demand that a collector
be able to express its timestamp correctly in either TAI or UTC.  For some
devices, especially those with limited network access or constrained
computational capacity, it might be onerous to demand that they reduce
their timestamps specifically to TAI.  But if they have the choice of
expressing in either TAI or UTC, it should be no problem for ledger
generating entities or ledger readers to perform the UTC->TAI conversion.

>Independent systems participating in the blockchain (e.g., as API server,
>or as consensus-forming systems) should have consistent opinions of TAI.
>Ledger timestamps (in TAI) need to be converted to the data consumer's
>desired time scale.

These are not difficult to achieve.  Since you only operate on
recorded timestamps, which are by definition in the past (or, with
clock inaccuracy, at most milliseconds in the future), you only need to
perform conversions for regions in which the relationship between TAI
and UTC has been established for some time.  There's a formal guarantee
that the relationship is established at least eight weeks in advance,
and actual current practice is to announce leap decisions about five
months in advance.  So the required conversion data always exists at
the time the conversion must be performed, but it may not have existed
at the time when a program was compiled or even when it started running.

So the entities that need to perform conversions need to know the table
of leap seconds, need to know the extent of the table they have, and need
to periodically extend the table as part of normal operation.  The table
can be extended by downloading it over the Internet from a couple
of well-known sources (<http://maia.usno.navy.mil/ser7/tai-utc.dat>,
<ftp://utcnist2.colorado.edu/pub/leap-seconds.list>).  There are security
considerations here, to which there are no well-established answers.

>   If good timescale conversion utilities exist, we would use them.

I wrote the Perl module Time::UTC, which performs excruciatingly correct
TAI<->UTC conversions.  In particular, it does download new data from
the sources I stated, and it strictly distinguishes between conversions
for which it has data and those for which it does not.  Aside from the
security considerations, this functionality meets your needs.  If Perl
doesn't suit you, it should at least be a good model to reimplement in
other languages.

There are many libraries that try to perform TAI<->UTC conversions
but use a fixed table of known leap seconds (those known when the
library was released) and are not capable of extending it at runtime.
These include Perl's DateTime module, Perl 6's Instant class, and Guile's
implementation of SRFI-19.  You should beware of this sort of library,
which is not at all suitable for your application.  Not only do they
in general fail to correctly convert current timestamps, but they tend
to not even know their limits, returning incorrect results rather than
signalling errors when their knowledge is exceeded.  All three that I
have listed make the very unrealistic guess that there will be no leap
seconds at all after the ones they know about.

-zefram