I am working on an app that tracks a users activity over time. When the user completes the activity I'd like to show the total time in minutes. Currently when the user passes 60 mins it resets the minute counter.
If a user is active for 1hr:2min I'd like it to show as 62 minutes. Is this possible? Currently it rolls over to 2 mins. This is what I have and it works great for under 60 minutes. I appreciate the feedback.
export const formatWalkTimeInMinutes = (walkSeconds) => {
return moment().hour(0).minute(0).second(walkSeconds).format('m');
};
'''
You can use
return moment.duration(walkSeconds, "seconds").asMinutes()
Related
I have been studying vesting schedules in blockchain lately. I wanted to test if the implementation of vesting works correctly. First i made a test that has duration of 24 months and cliff duration of 6 months. After testing everything worked correctly, so I decided to create another test but in seconds. Here is the implementation:
it("Should be able to vest gradually (in seconds)", async () => {
// deploy vesting contract
let tokenVesting: TokenVesting = await new TokenVesting__factory(owner).deploy();
await tokenVesting.deployed();
await tokenVesting.initialize();
// send tokens to vesting contract
await expect(saleToken.transfer(tokenVesting.address, 1000))
.to.emit(saleToken, "Transfer")
.withArgs(owner.address, tokenVesting.address, 1000)
const currentBlock = await hh.ethers.provider.getBlock(await hh.ethers.provider.getBlockNumber());
let now: number = currentBlock.timestamp;
let vestingId = "vesting id";
let initiallyReleasablePercentage = 0;
let startTime: number = now + 1; // current time
let duration: number = 10; // 10 seconds
let cliffDuration: number = 4; // 4 seconds
let slicePeriodSeconds = 1; // 1 second
await tokenVesting.createVesting(
vestingId,
saleToken.address,
startTime,
duration,
cliffDuration,
initiallyReleasablePercentage,
slicePeriodSeconds
);
await saleToken.connect(owner).approve(tokenVesting.address, hh.ethers.utils.parseUnits("10", 18));
await tokenVesting.vest(vestingId, owner.address, hh.ethers.utils.parseUnits("10", 18));
/**
* vested amount should be 0 for the next 4 seconds, because cliff duration is 4 seconds
*/
expect(await tokenVesting.getReleasableAmount(tokenVesting.address, vestingId)).to.equal(0);
/**
* go ahead by 5 seconds -> current time is 5 seconds,
* should be able to vest 5 tokens because it reached cliff start time
*/
await hh.ethers.provider.send("evm_increaseTime", [5]);
await hh.ethers.provider.send("evm_mine", []);
expect(await tokenVesting.getReleasableAmount(owner.address, vestingId)).to.be.equal(5);
}
In this code first 10 lines are for deploying vesting contract and sending tokens to it. Then get current time using block.timestamp. Then I create fields that will be used to createVesting. duration is the total duration of a vesting, cliffDuration is cliff time, so time after which we can vest tokens and slicePeriodSeconds is the time that we have to wait after the previous release. Then under the tokenVesting.createVesting I send tokens to the user that will be tested and the amount is 10 and then testing starts.
Here is the problem
First test works fine because the releasable amount is 0. But then when I jump to the future by 5 seconds and test it, the test cracks. It shows that the releasable amount is 7 tokens but it should be 5 because we jumped to the middle of the token vesting period and total amount of tokens is 10.
My thoughts
It got me thinking that in these tests, time does not stop. It is going further. So when I jump by 5 second it logs time before and after creating vesting but when i m trying to getReleasableAmount the time passed and in this function gives me wrong amount of tokens. I don not really know if this is correct it is just my assumption.
Is it possible to somehow stop the time in hardhat testing after evm_increaseTime? When I tested the code but evm_increase_time was in months everything worked and releasable amount was as expected. But trying to test it in seconds when total vesting time is 10 seconds and cliff duration is 4 seconds it is not working as expected.
Has anybody had similar problem or know the solution to that (e.g. stopping the time in hardhat or something else)?
I have Splunk alert which runs query every 15 min for last 30 min.
My savedsearch.conf looks like this:
dispatch.earliest_time = -30m#m
cron_schedule = */15 * * * *
But anyway, I am getting alert every 30 min, not 15 min. First one I got at 10:55 AM and the next one at 11:25
At 10:55, the alert triggered and started a 20-minute timer. At 11:10, the alert triggered again, but the timer still had 5 minutes left on it so no alerts were sent. Finally, the alert triggered at 11:25, the suppression timer had elapsed, so the alert was sent and a new timer started.
I have an API created with Laravel 5.2. I am using throttle for rate limiting. In my route file, I have set the following..
Route::group(['middleware' => ['throttle:60,1'], 'prefix' => 'api/v1'], function() {
//
}
As I understood the Laravel throttling, the above script will set the request limit to 60 per minute. I have an application querying the route which repeat every 10 seconds. So, per minute there are 6 request which is much more satisfying the above throttle.
Problem is, my query works until I execute 60 request regardless of time and after 60 request, it responds me 429 Too Many Requests with header Retry-After: 60. As per my understanding, the X-RateLimit-Remaining should update every 1 minute. But it seems never updated until it goes to 0. After become zero, then waits for 60 seconds then updated.
Am I doing anything wrong here.
I need to setup a Gatling Test with a total of 50 concurrent users, but I have a problem because there is no choice to get it.
I use rampUsers(10) over (60 minutes) but it gets only 10 concurrent users.
Using constantUsersPerSec(users) during (60 minutes) is too stressful.
Is there any suggestion?
Thanks.
This could be done as follow:
val scn = scenario("Test").during(1 hours) {
exec(http("test").get("/"))
}
setUp(scn.inject(splitUsers(50) into atOnceUsers(10) separatedBy(5 minutes))
.protocols(httpConf))
see http://gatling.io/docs/2.0.3/general/simulation_setup.html:
splitUsers(nbUsers) into(injectionStep) separatedBy(duration): Repeatedly execute the defined injection step separated by a pause of the given duration until reaching nbUsers, the total number of users to inject.
If you register a BackgroundTask with a recurring TimeTrigger (OneShot set to false), when does the first occurrence run? After the first FreshnessTime minutes or before?
Microsoft documentation states:
If FreshnessTime is set to 15 minutes and OneShot is false, the task
will run every 15 minutes starting between 0 and 15 minutes from the
time it is registered.
edit
I tested this a few times and it seems to run the first occurrence at anytime during the 15 minute period after registration. It then runs future occurrences at regular 15 minute periods based on 15 minutes from the start time of the previous run.
I'm not sure internally how the OS is scheduling the timer cycles but the answer to your question is not after, not before but during.
nb. You cannot get any timer background task to fire immediately.