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 _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
