use a fuzzy match when computing whether the current time is a trigger date

[kapil1garg]

In simulation, a simple match with currDate.getTime() === currOpportunity.trigger_date.getTime() will work fine since the simulation is setting and locking the internal clock while the code executes. In deployment, this will fail if even a couple milliseconds (what getTime() returns) are off.

We could instead use a time window depending on the kind of trigger:

• during(venue): up to 10 mins after a venue has started.
• before(venue, timeBefore): up to 10 mins before venue's time - timeBefore
• after(venue, timeAfter): up to 10 mins after venue's time + timeAfter

This should give a plenty large enough window even if many scripts are running and take a few seconds to complete.

[kapil1garg]

instead of the time windows, could round down to the minute and check day, hours, minute (ignore seconds and milliseconds). in the execution code, store this at the function-level and use this time against all detectors/feedback instead of calling getTime() when each runs (since they take time, it could push it out of the 60 second buffer that this solution provides)