I wanted to get a start time of solidity code, so I used now() previous which only returns block.timestamp whenever the solidity got started.
Is there any way to store or know the start time of solidity code which is typically elapsed time in other programming language. In case of Javascipt, it is simple to calculate the elapsed time of code as below.

var start;
var end;
var elapsed;

function startTime() {
   start = new Date();

function endTime() {
   end = new Date();
   elapsed = end - start; 

I have tried to calculate the time difference in solidity like that, but it has shown only block time stamp for the now function. Is there any way to find the start time in solidity?

1 Answer 1


The short answer is No.

What you are trying to do doesn't map to how this platform works. Normal assumptions about temporal time don't apply. Normal intuitions about execution time don't apply.

The blockTime is the only, admittedly tenuous, connection to temporal time available.

I'll break that down a little more.

Nodes process all transactions, but they don't learn about the blocks at the same time. In temporal terms, the start time is unique to each node processing the transaction. Same for the finish. As well as when a node starts working on it, other factors are in play, e.g. node performance.

So, start time depends on which node you observe, as does the finish time. Everyone hears about the block at a different time, are they are hearing about a transaction that was already processed - by the network, in the past. The most a node can hope to do is catch up to "now" as quickly as possible. Outside of their own performance, there is no way to measure start, finish or duration of a transaction. The transaction was already done before the block even arrived.

Think of the block as a well-ordered set of transactions that all execute sequentially and instantaneously. The moment this is deemed to have taken place is the timestamp for the block.

pragma solidity 0.5.11;

contract Elapsed {

    function stopwatch() public view returns(uint duration) {
      uint start = now;
      for (uint i=0; i<9999; i++) {
        // busy busy busy
      uint end = now;
      duration = end - start;

That's busy enough to make Remix seize up for a few seconds and still, it returns 0 every time. There are no other hidden gems to help get the expected result.

Also worth mentioning is that all processing and results need to be replicable by all nodes, now and in the future. A subjective factor such as duration or a given node's accurate clock would not work because it wouldn't be deterministic. For this reason, I think it is theoretically impossible.

Hope it helps.

  • Your answer is clear for this question. It is impossible to use now() to calculate the elapsed time in solidity code. However, is there any function except now() to get current time in solidity or other ways to find it?
    – JongH
    Commented Nov 19, 2019 at 6:10
  • 1
    The only way external time can get in there is if someone signs a transaction and provides it, a.k.a. an Oracle. That would, in effect, transfer the trust from the code, blockchain, miner and contract to the Oracle. No one really knows what time it is, but they would know what the Oracle said it was. Commented Nov 19, 2019 at 7:39
  • Would you explain about that if someone signs a transaction and provides it. I tried to test the Oracle to get the start time of code, but it should be deployed and called by someone to get the time from Oracle which responses for a while though. So, the result of current time was later than the block stamp time.
    – JongH
    Commented Nov 19, 2019 at 20:04
  • Suppose you have a contract with function(uint t) ... ... then you, someone else, or a trusted Oracle sends t which could be network time, and quite accurate - probably before the blockTime because that transaction will be pending for a while before it's mined. You can do validity checks, to a point, but the contract cannot reliably compare it to "actual" time. There is also the question of whether is telling the truth and always will because it could compromise the security of any logic that depends on this number. Commented Nov 20, 2019 at 1:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.