question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

calling `evm_mine` with a `timestamp` does not persist time offset

See original GitHub issue

Discussed in https://github.com/trufflesuite/ganache/discussions/3264

I’m opening as an issue as suggested by @davidmurdoch

<div type='discussions-op-text'>

Originally posted by msuscens June 21, 2022 Hello,

I have Truffle tests that successfully pass with Ganache v6 but fail with Ganache v7.3.1. The truffle tests in question use the ganache-time-traveler utility to advance time. Specifically, the issue is with functions that need a certain amount of time to pass before they will execute (without reverting). I, therefore, use ganache-time-traveler to advance the time before executing the function. Unfortunately, with ganache 7.3.1 these functions revert even though time has been advanced by the required amount. Here is an example:

describe("After Incubation: Hatch single egg", () => {

        let snapshotId
        beforeEach("Advance Time to End of Incubation", async() => {
            let snapshot = await timeMachine.takeSnapshot()
            snapshotId = snapshot['result']

            // Incubate for required time
            await truffleAssert.passes(
                timeMachine.advanceTimeAndBlock(INCUBATION_DURATION),
                "Failed to advance time and block"
            )
        })

        afterEach("Revert To Start of Incubation Time", async() => {
            await timeMachine.revertToSnapshot(snapshotId)
        })

        it("should allow egg owner to hatch it, emitting an Hatched event ", async () => {
            let txResult
            await truffleAssert.passes(
                txResult = await eggToken.hatch(
                    [0], //eggids
                    {from: accounts[2]}
                )
            )
            truffleAssert.eventEmitted(txResult, 'Hatched', (ev) => {
                return equals(toNumbers(ev.hatchlingIds), [0]) &&
                    equals(toNumbers(ev.eggIds),[0]) &&
                    ev.owner == accounts[2]
            }, "Event Hatched has incorrect parameter values!")
        })

etc …

This test passes with Ganche v6 but eggToken.hatch reverts under v7.3.1 with the following message:

After Incubation: Hatch single egg
         should allow egg owner to hatch it, emitting an Hatched event :
     Transaction: 0x20883a2a3329b9925a86499b4fe1e9727a029f197d00f084ed920e94eb1954d6 exited with an error (status 0). Reason given: hatch: Egg not incubated!.
     Please check that the transaction:
     - satisfies all conditions set by Solidity `require` statements.
     - does not trigger a Solidity `revert` statement.
 
  StatusError: Transaction: 0x20883a2a3329b9925a86499b4fe1e9727a029f197d00f084ed920e94eb1954d6 exited with an error (status 0). Reason given: hatch: Egg not incubated!.
      at Context.<anonymous> (test/2.eggToken/6.eggToken_hatch_gen0_test.js:217:43)
      at runMicrotasks (<anonymous>)
      at processTicksAndRejections (internal/process/task_queues.js:93:5)

I’d appreciate any help/advice on how to resolve this issue.

I’m on a 2022 MacBook Pro (M1 Pro processor): MacOS 12.4 Truffle v5.5.3 (core: 5.5.3) Ganache v7.0.1 Solidity - 0.8.13 (solc-js) Node v14.15.5 Web3.js v1.5.3

Note: Even though it says “Ganache v7.0.1” above (from ‘truffle version’), I’ve installed v7.3.1 and when I start ganache (via CL) it says “ganache v7.3.1 (@ganache/cli: 0.4.1, @ganache/core: 0.4.1)”

</div>

Issue Analytics

  • State:closed
  • Created a year ago
  • Comments:9 (7 by maintainers)

github_iconTop GitHub Comments

3reactions
MicaiahReidcommented, Aug 8, 2022

@jeffsmale90 this is an issue and not a PR, so I don’t think we should close it until the fix is merged 😄

3reactions
MicaiahReidcommented, Jun 22, 2022

Great find, @davidmurdoch!

@msuscens, hopefully using the --miner.timestampIncrement 1 flag will suffice as a workaround until we get a fix released.

Read more comments on GitHub >

github_iconTop Results From Across the Web

How to store date/time and timestamps in UTC time zone with ...
Since Hibernate 5.2, you can now force the UTC time zone by adding the following configuration property into the properties.xml JPA configuration file:...
Read more >
Postgres: why does to_timestamp return the date with different ...
If you want all timestamps shown with the same UTC offset, choose a timezone setting that has no daylight savings time, for example...
Read more >
Timestamps, Time Zones, Time Ranges, and Date Formats
Learn how Sumo Logic manages timestamps, time zones, time ranges, and dates, and the configuration options that are available.
Read more >
JavaScript: Creating timestamps with time zone offsets
I need to find correct amount of seconds from Unix epoch so users can save times based on their region and not by...
Read more >
Modifying Timestamps (Offset) - Rev.com Help Center
How do I adjust the timestamps to match my burned-in timecode? You can offset the start time of your timestamps easily in our...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found