HardhatNetworkHelpersError: Invalid timestamp 1657236743 is not larger than current timestamp 1716852786

[Hirama]

Cant manipulate with correct timestamp.

"hardhat": "^2.10.0" "@nomicfoundation/hardhat-network-helpers": "^1.0.2"

The code

console.log("Now:", Math.floor(Date.now() / 1000))
console.log("Latest:", await time.latest());
await time.setNextBlockTimestamp(Math.floor(Date.now() / 1000));

Console

Now: 1657236743
Latest: 1716852786

Error HardhatNetworkHelpersError: Invalid timestamp 1657236743 is not larger than current timestamp 1716852786

[github-actions[bot]]

This issue is also being tracked on Linear.

We use Linear to manage our development process, but we keep the conversations on Github.

LINEAR-ID: 497cf789-4bc5-4f9f-9ad7-9f65b0be2073

[alcuadrado]

Hey! Thanks for reporting this issue so quickly 🙌

Are you forking a remote network?

[Hirama]

Hey! Nope, just running the tests

[feuGeneA]

Hey! Nope, just running the tests

Which tests? Something you can point us to?

[Hirama]

Hey! Nope, just running the tests

Which tests? Something you can point us to?

npx hardhat test

The problem is that block.timestamp returns time from distant future

[feuGeneA]

Thanks for the response, but that doesn't quite answer the question. You've told us that you're running the tests within a Hardhat project, but you haven't shared with us which project it is that you're running the tests for. Can you share your Hardhat project with us? Perhaps via a GitHub repo, or a .zip file attached to this Issue?

[joglea]

@feuGeneA My hardhat project has similar problem . I run the "npx hardhat node" . When I repeat test my script "test/Lock.js" ,the local hardhat node's block.timestamp is bigger and bigger than my local timestamp. first the block.timestamp is smaller than my local timestamp: npx hardhat test test/Lock.js

... after run my test script for several times, the block.timestamp is bigger than my local timestamp:

the block.timestamp will get bigger

my test project's zip file :

test-hardhat.zip

[kasoqian]

The reason I found this solution is because there is another test file which is named Lock.sol and this file has a modified timestamp in it. Just comment out this default file.

like this:

 // const unlockTime = (await time.latest()) + ONE_YEAR_IN_SECS;

@alcuadrado @joglea @Hirama @feuGeneA

[kasoqian]

@feuGeneA My hardhat project has similar problem . I run the "npx hardhat node" . When I repeat test my script "test/Lock.js" ,the local hardhat node's block.timestamp is bigger and bigger than my local timestamp. first the block.timestamp is smaller than my local timestamp: npx hardhat test test/Lock.js

... after run my test script for several times, the block.timestamp is bigger than my local timestamp:

the block.timestamp will get bigger

my test project's zip file :

test-hardhat.zip

look! You have the Lock test file, delete it that will work!

[vladikopl01]

I had the same problem while running tests. Every test with expected equals for latest() and the block.timestamp causes test failure and has a difference in time of 1 sec. I make data struct on contract based on latest() timestamp and then get back this struct to expect creating process was performed without issues, but get the difference in time.

Here is my test case:

it('fail - invalid start date', async () => {
      const actionWallet: SignerWithAddress = bcdOwnerWallet;
      const saleInfo: SaleInfo = {
        ...defaultSaleInfo,
        startDate: toBN((await latest()) - 1000),
      };

      const salesCounterBefore = await bcdContract.connect(actionWallet).getSaleCount();

      await checkContractOwner(actionWallet.address, bcdContract, true);

      await expect(createSale(bcdContract, actionWallet, saleInfo))
        .to.be.revertedWithCustomError(bcdContract, CustomErrors.INVALID_START_DATE)
        .withArgs(saleInfo.startDate, await latest());

      const salesCounterAfter = await bcdContract.connect(actionWallet).getSaleCount();
      expect(salesCounterAfter).to.be.eq(salesCounterBefore);
    });

So, I had a saleInfo data object which I expected not to be added as Sale struct to the contract's state, because of raised custom error on contract. It should be reverted with such parameters as saleInfo.startDate and block.timestamp which should be equal in test to saleInfo.startDate and latest(), as latest() should return block.timestamp time, but it differs just for 1 sec.

[vladikopl01]

I had the same problem while running tests. Every test with expected equals for latest() and the block.timestamp causes test failure and has a difference in time of 1 sec. I make data struct on contract based on latest() timestamp and then get back this struct to expect creating process was performed without issues, but get the difference in time.

Here is my test case:

it('fail - invalid start date', async () => {
      const actionWallet: SignerWithAddress = bcdOwnerWallet;
      const saleInfo: SaleInfo = {
        ...defaultSaleInfo,
        startDate: toBN((await latest()) - 1000),
      };

      const salesCounterBefore = await bcdContract.connect(actionWallet).getSaleCount();

      await checkContractOwner(actionWallet.address, bcdContract, true);

      await expect(createSale(bcdContract, actionWallet, saleInfo))
        .to.be.revertedWithCustomError(bcdContract, CustomErrors.INVALID_START_DATE)
        .withArgs(saleInfo.startDate, await latest());

      const salesCounterAfter = await bcdContract.connect(actionWallet).getSaleCount();
      expect(salesCounterAfter).to.be.eq(salesCounterBefore);
    });

So, I had a saleInfo data object which I expected not to be added as Sale struct to the contract's state, because of raised custom error on contract. It should be reverted with such parameters as saleInfo.startDate and block.timestamp which should be equal in test to saleInfo.startDate and latest(), as latest() should return block.timestamp time, but it differs just for 1 sec.

I realized that latest() function returns the latest block timestamp and my custom error returns block.timestamp of the possible next block, so there is a difference in 1 sec between them.

It will be great to have such a function to get the next possible timestamp of the block, which is proceeded by the current transaction, if it is possible at all. Anyways, I will be glad to hear any ideas on how to resolve my problem appropriately.

[fvictorio]

There seem to be a couple of problems going on here.

The first issue, about the timestamp being way in the future... I don't know what's going on. And I don't think we can figure it out without reproduction steps.

When I repeat test my script "test/Lock.js" ,the local hardhat node's block.timestamp is bigger and bigger than my local timestamp.

This is probably caused by Hardhat increasing each block's timestamp by at least one second. We do this to follow the consensus rule that dictates that each block must have a different timestamp, but we are going to introduce an option to relax this condition.

I realized that latest() function returns the latest block timestamp and my custom error returns block.timestamp of the possible next block, so there is a difference in 1 sec between them.

It will be great to have such a function to get the next possible timestamp of the block, which is proceeded by the current transaction, if it is possible at all. Anyways, I will be glad to hear any ideas on how to resolve my problem appropriately.

This would be hard to do because, in the normal case, the next block timestamp depends on, well, when the block was mined.

What you can do is to use setNextBlockTimestamp to set the timestamp of the new block and then compare that in your test.

---

I'm going to close this issue now. If someone still has some problem, please open a new issue.