Unexpected behavior with `block.timestamp` in truffle test

• [O] I’ve asked for help in the Truffle Gitter before filing this issue.

---

Issue

According to the documentation, block.timestamp should be the timestamp of the last mined block.

However, in truffle test environment, block.timestamp keeps increasing(seemingly the current timestamp) when returned in a view function.

Calling the function manually through web3 interface, it returns the expected value(unchanged timestamp of last mined block).

Steps to Reproduce

Fork https://github.com/vzts/block-timestamp-test, setup local mining node(e.g. ganache), run truffle test.

Below is the minimum example code: (in a solidity contract):

function test() public view returns(uint, uint) {
    return (block.timestamp, block.number);
}

(in a truffle js test case):

it("test", async function () {
    for (let i = 0; i < 100; i++) {
        console.log(await contractInstance.test())
        sleep(1000) // pseudo code for sleep
    }
})

Expected Behavior

Should return the same timestamp and the number for the last mined block upon every request (in an environment where no new transaction is executed(no new block is mined))

Sample output:

[“1524690793”, “157”] [“1524690793”, “157”] [“1524690793”, “157”] [“1524690793”, “157”] [“1524690793”, “157”] [“1524690793”, “157”] [“1524690793”, “157”]

Actual Results

Returning the “current”(not sure what is happening, but it seems so) timestamp.

Sample output:

[“1524690799”, “157”] [“1524690800”, “157”] [“1524690801”, “157”] [“1524690802”, “157”] [“1524690803”, “157”] [“1524690804”, “157”] [“1524690805”, “157”]

Environment

• Operating System: macOS High Sierra 10.13.4
• Ethereum client: Ganache 1.1.0
• Truffle version (truffle version): 4.1.7
• node version (node --version): 8.4.0
• npm version (npm --version): 6.0.0

[cgewecke]

@vzts Update, just had a chat with @benjamincburns, the engineer who writes ganache. He suggested there’s enough ambiguity about correct behavior here that we should really look at how geth and parity handle this. If they both let the clock tick, ganache should tick. If only one lets the clock tick, ganache should side with keeping block.timestamp fixed at the latest block because that’s more intuitive (and more useful for tests ).

[cgewecke]

@vzts Update: Have run your test against both geth dev and a Parity POA network and both report a static time within the block, so Ganache’s behavior is non-normative. Will report back to @benjamincburns and open a PR over there fixing this.

Hope you don’t mind but I’m going to close this and open a referral issue over there. Thanks again for discovering this.