Eric, and time nuts -- A very nice set of questions and an interesting application. In fact it's so time nutty that I'll send it over to the LEAPSECS mailing list, which is the niche of time-nuts where we deal with issues of UTC, TAI, and leap seconds. You can pick up your replies there.
LEAPSECS -- please help Eric out. I know there are answers from bloated universal date/time packages to one page of elegant code. Thanks, /tvb LEAPSECS mailing list leaps...@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs ----- Original Message ----- From: "Eric Scace" <e...@scace.org> To: "Discussion of precise time and frequency measurement" <time-nuts@febo.com> Sent: Tuesday, December 13, 2016 5:50 AM Subject: Re: [time-nuts] Time math libraries I should clarify my intended application for “time math”. My company is deep in development of a system that, in part, records events on a blockchain. For various reasons a precise and accurate representation of time of the event can be important. How precise and accurate depends on the application. The first applications need millisecond precision and tens of millisecond accuracy — not a huge demand by TimeNut standards, but not to be neglected. Leap seconds (and the differing contortions being used by various organizations to evade implementation of leap seconds) should not be ignored. The blockchain runs as a generic event-recording ledger utility supporting many applications. Over time, we will need to get more precise and accurate on time. To be general, we take the following approach: Timestamp (and, often, geolocation) are acquired at the point of measurement for the data set. This is treated as the opinion of the collecting device. We record meta-data about the collecting device. For some applications the meta-data includes information as to how the device formed its opinion of time. The application submits the event to the ledger service’s API for recording. The API server(s) timestamp the client’s request to record to the ledger. This timestamp is relatively important because it is the declaration of the ledger, an immutable reference of the sequence of events, upon which other systems will rely in future. The present scheme is to use TAI as the timescale for all events recorded to the ledger. Some of the implications: Collecting device timestamps may need to be convertible to TAI. This task can be a mess, because the sources of time opinions may be vast; e.g., cell phones, AWS, Google, MS Azure, etc. We work around this by capturing meta-data about the device’s timescale and source. This allows retrospective consideration of the devices’ time opinion relative to TAI when it is important for the downstream data consumer. 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. Here’s another instance of the need for a set of time math utilities. I realize this description also opens a Pandora’s box that involves distribution of time issues. But, for the purposes of this thread, I wanted to focus on the TAI-to-other-timescales conversion utility question. If good timescale conversion utilities exist, we would use them. If good timescale conversion utilities do not exist, then maybe we’ll contribute one to the open software space. — Eric _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
