hardhat
hardhat copied to clipboard
HardhatNetworkHelpersError: Invalid timestamp 1657236743 is not larger than current timestamp 1716852786
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
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
Hey! Thanks for reporting this issue so quickly 🙌
Are you forking a remote network?
Hey! Nope, just running the tests
Hey! Nope, just running the tests
Which tests? Something you can point us to?
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
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?
@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 :
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
@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 :
look! You have the Lock
test file, delete it that will work!
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 had the same problem while running tests. Every test with expected equals for
latest()
and theblock.timestamp
causes test failure and has a difference in time of 1 sec. I make data struct on contract based onlatest()
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 assaleInfo.startDate
andblock.timestamp
which should be equal in test tosaleInfo.startDate
andlatest()
, aslatest()
should returnblock.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.
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.