Kimmo Huoman
Kimmo Huoman
At the same time, the format of Elbas data should be changed. It would be more logical to group the data first by product type (PH, 2H, 4H, DON, DB,...
IMO the current behavior is correct. The last run as been before the code should have been last triggered. Everything the `*/10` does is tell that the run should occur...
hmm, that indeed does seem like a bug, let me double check
Hmm, this is actually bit of a tricky one. As cron _doesn't handle seconds_, the `last_run` at 15:30 is the cause for trigger. As the `last_run` matches, it's reported as...
As you can see, both tests include the 15:30:00 -> both should return True, as 30 is a minute when the cron matches. If you try with minutes 31 and...
In essence, this could be solved if before https://github.com/kipe/pycron/blob/master/pycron/__init__.py#L132 `since` would be increased by 1 minute, as it's done in the loop. And then behavior in this case would be...
Yeah, the behavior seems correct. But as cron doesn't care about seconds, this can be fixed just by adding 1 minute before the loop to `since`. Would be a fine...
Here, the issue is that ``` 2021-11-12 15:29:00 2021-11-12 15:30:51 True 2021-11-12 15:30:00 2021-11-12 15:31:51 True ``` both include the trigger time in either start or end times -> True....
Hey, thanks for your work! What interests me is when you say "slow when converting/comparing a large array of datetime values". What kind of usage are we talking about? My...
I'm perhaps more interested in a real-life scenario where this would be used.