block.timestamp a.k.a now in constant functions

jwgcarlylejwgcarlyle Member Posts: 29
edited July 2015 in Solidity
I had a function which wasn't working in a test environment : I was doing something stupid and wanted to share, in case it catches other people out.

I was testing for an end time of an auction / crowdfunding opportunity / reward scheme against the Solidity property "now", which I was calling rather than sending a transaction. Because it's not necessary to be mining for the call to work, the now property was not being incremented, and was reflecting the timestamp of the last time that mining occurred on the test node, rather than the current time on the node.

So be careful using "block.timestamp" or "now" in "constant public" functions :smile:
Post edited by StephanTual on


  • jwgcarlylejwgcarlyle Member Posts: 29
    Actually I'd appreciate a strict definition of what "now" really means.

    It does not seem to be the timestamp of the block of the current transaction according to the behaviour I thought I saw - e.g. when I set up a contract state variable "endTIme" and then wait until it has passed, then send a transaction to a function which checks "now > contract.endTime", then switch on mining just to mine that transaction, the condition returns false. If I then send another transaction to the same function, the condition returns true.

  • StephanTualStephanTual London, EnglandMember, Moderator Posts: 1,282 mod
    edited July 2015
    Hi @jqgcarlyle, actually your question was brought up on one of our channels and Gav replied with this: "The return of block.timestamp can only be given as a best effort as will all other external execution environment parameters. Fundamentally, they're impossible to "know", except on the final mine, and since constant functions are never mined, they can never be properly defined. In cpp they take on values as they would if the client were about to mine them. It's a misunderstanding of the execution environment to believe 'now' would be wall time; all language is taken from the perspective of the contract executing, not from the user authoring/running."

    I hope this helps!
  • samsam San FranciscoMember Posts: 9
    In execution land, block timestamp of the 'pending' block is when your node finished processing the 'latest' accepted block and started forging it's next block. It is hoping that it's the next mined block, but it probably won't be.

    You can still count on it as being a time that has happened in the past for contract logic as long as your node has ntpd.
Sign In or Register to comment.