[time-nuts] imprecise but adequate time

[K5ROE Mike]

If the data collected by your system could potentially be used in 
litigation , I would reconsider your accuracy requirement, especially 
the OKness of simultaneous transactions.

I assume that all nodes can write to the blockchain; how do you sanity 
check if one node's clock is wildly off?

Since you don't control the operating system, but do control the 
application code, you may want/have to maintain time in your application.

Since everybody is writing to the same chain, I don't see how you can 
not use a mutual time reference among the nodes.


On 5/28/19 10:38 AM, Eric Scace wrote:
> Hi fellow time nuts —
>
>     I’m looking for a sanity check or alternative suggestions for the problem and tentative solution described below.
>
>     Thanks for your thoughts.
>
> — Eric
>
> Problem:
>
>     In one of my day jobs, I am designing a global network of systems (using open-source software) that provide well-researched information about rights and licenses for musical works (e.g., songs, compositions).
>
>     Claiming rights, registering licenses (some of which are temporary), and time-stamping changes to data each exemplify cases where date/time must be included. In many cases the time order of events can be important — potentially changing who gets paid how much when music is performed or distributed.
>
>     The machines are scattered around the planet and the usual problems of time distribution exist. Furthermore, systems are operated independently. We assume  occasional use of NTP to correct system clocks, but not a local GPS-provided time. The software development team is generally oblivious to the issues of time in distributed computer networks.
>
>     A grim picture — but, fortunately, this application does not require high precision time.
>
> My tentative proposal:
>
>     1. To avoid burdening systems with multiple local time conversions, all date/time information throughout the system shall be UTC. Implications:
> user apps will be responsible for converting from a human user’s local time to UTC
> thus, user app developers will have to do this conversion correctly
>
>     2. Date/time stamps in the data shall be rounded to the nearest EVEN second by the system instances; e.g., to 2019 May 28 14:24:28 UTC. Implications:
> user apps that submit claims or updates will have their claims/updates date/time-stamped by the receiving system node with this rounding method. Example: “John Smith claims that he and Jane Doe wrote these lyrics, making an equal contribution between them, on 2019 May 27 15:00:00 UTC. His claim was received by the system at 2019 May 28 14:26:50 UTC.” One or more blockchain ledgers record a hash of the musical work [the lyrics, in this example], the claim [who wrote the lyrics when], and which app/system registered the claim and when.
> events occurring roughly within ±1 second of each other will be deemed to have occurred simultaneously. This is entirely adequate for this application.
> competing leap second smearing methods employed by different operating systems and data center operators will be washed out of the time stamp by this rounding requirement.
>
> — end —
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.