Bug in steps calculation
See original GitHub issueThe calculation of prev
execution from the current time does seem to return None
when
the current time is 1st of every month and previous month is less than 31 days.
This happens regardless of whether you pass LocalDate
or LocalDateTime
ex: If the cron expression is val cron = cron"0 0 0 * * ?" (daily)
, then cron.prev(LocalDate.of(2019, 3, 1).atStartOfDay)
returns None (Feb has less than 31 days) and cron.prev(LocalDate.of(2019, 4, 1).atStartOfDay)
returns 31st of March
.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:1
- Comments:11 (6 by maintainers)
Top Results From Across the Web
Metrics for Bugs in User Stories and Features | Targetprocess
In this case, total bugs count / effort / time spent / cost for the Feature should include the Bug just once, not...
Read more >The Bug Formula - Hintjens.com
Bug formula : U = (R / S - 1) B + S - R. Let us try to follow the steps in...
Read more >Bug - Incorrect calculation of steps/step length · Issue #52
This divides the width into steps based on the number of options in the array, rather than the number of gaps between each...
Read more >Defect Management Process in Software Testing (Bug Report)
Steps – Detailed steps along with screenshots with which the developer can reproduce the defects. Date Raised – Date when the defect is...
Read more >A calculation bug for Excel? - Microsoft Community Hub
Hi, I would like to report a bug occurred with my excel. ... Please enlighten me if I have any wrong steps. Many...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
that’s actually valuable feedback, and a good reason to not remove it
Thanks @dave-handy, I see your point, your workaround is probably your best bet right now but agree that counter-intuitive and suboptimal.
I do see value in having a
prev
operation and that’s why I’ve been reticent of removing it. I’ll try to steam up and attempt to fix it with the new approach.