Ledger API Nodejs SDK : getTime() not implemented

Ledger API Node JS sdk version : 0.8.3 NodeJS Version : 10.19.8

Issue: Code fails when trying to access ledger time using NodeJS SDK. Ledger is running in wallclock mode.

Example Code

const ledger = require('@digitalasset/daml-ledger');

getTime = () => {
  ledger.DamlLedgerClient.connect({ host: 'localhost', port: 8080 }, (err, client) => {
    let ledgerTime = client.timeClient.getTime()
    ledgerTime.on('data', response => {
      console.log(response)
    })
  });
}

getTime();

---

Exception

events.js:174
      throw er; // Unhandled 'error' event
      ^

Error: 12 UNIMPLEMENTED: Method not found: com.digitalasset
.ledger.api.v1.testing.TimeService/GetTime

[bame-da]

@ashfaq-shaik , I think you are spot on in saying that the Ledger should give a single useful notion of time. As @SamirTalwar-DA is saying, it’s actually far from trivial to do so, though, which is why having a sound notion of LedgerTime is pretty unique to DAML - I’m not aware any other DLT has something comparable.

It being difficult, there are trade-offs. System clocks on different components of the distributed network will diverge and have skews, there will be network latencies, and processing large batch transactions will take time. Time being a distributed concern also means that it is not as observable as one may think. DAML’s value prop is that applications that run on the Sandbox run on highly distributed networks, too, so we consciously don’t expose more via the API than we can offer in the most general case. Every transaction can be assigned a time stamp that makes sense, but there is no clock you can poll via a service to find out the current ledger time precisely.

The DAML Time model is pretty simple at the core:

• Every transaction gets a Record Time (RT) assigned as part of sequencing/consensus
• Every transaction gets a Ledger Effective Time (LET) assigned as part of submission
• Every DAML Ledger has “skew” parameters s_min and s_max, and valid transactions require RT - s_min <= LET <= RT + s_max
• The LET of a transaction must be greater or equal to the LET of any input contract. Ie an exercise, fetch, or archive always happens after the create in Ledger Time

The skew parameters give you the degree of “fuzziness” in Ledger time. I believe in the sandbox they are 1s, but I’d need to double check. That means you can backdate your transaction by up to one second, but only if it doesn’t have any contracts created within the last second as input. The bigger the skew parameters, the fuzzier Ledger Time becomes, but the smaller the skew parameters are, the harder it becomes to set LETs that satisfy the constraints. So setting those skew parameters is a trade-off in practice.

That means Ledger Time for Sandbox ledgers is Sandbox host system time ± 1s. There is no service to poll this as that service would be nearly impossible for more distributed ledgers. The JSON API assumes that Ledger time is it’s own system time right now, which means it’s best run on the same machine as the Sandbox. It should then work seamlessly without adjustment.

There are some cases currently where running components on different machines with clock skews can lead to bouncing transactions. We are therefore working on moving the determination of ledger time (LET) even closer to the ledger, which should make it work seamlessly in almost all cases. However, it still won’t be queryable, but only observable by previous transactions and based on the assumption that system clocks are reasonably in sync.

My general recommendation, which should work in the most general case, would be to

• Find an acceptable fuzziness parameter for the system as a whole (e.g. 1 minute)
• Use NTP or similar services to make sure all machines are kept within an interval of that length
• Assume that local system time is equal to ledger time The ledger will take care of the rest, though the LET you actually end up with may be different from what you thought it would be by up to the fuzziness parameter.

[ashfaq-shaik]

Thanks for the explanation @bame-da . This helps.