Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support expand_from_start_time #76

Closed
wants to merge 1 commit into from
Closed

Conversation

mghextreme
Copy link
Contributor

Issue

When unsing the library, we wanted to generate dates using the cron on a repeat (e.g. every 7 days with cron 0 0 */7 * *), but, even though we set the start_time, the library just uses preset values to generate the possible dates.

Code

A new parameter was added when creating a croniter instance - expand_from_start_time. When True, the expnaded values will be generated based on the start_time date set when creating the instance.

Current behavior

0 0 */7 * *, start time today (2024-07-11): get_next() would generate 2024-07-15 (4 days from now) ❌

New behavior

0 0 */7 * *, start time today (2024-07-11): get_next() would generate 2024-07-18 (7 days from now) ✅

Only if the new parameter is set to True

Important

Because the expanded values are generated when creating the croniter instance, using expand_from_start_time=True and setting start_time on the get_next() method is not supported.

Changes

I made the initial changes, but wanted the opinion of the mantainers before moving forward with the changes.

  • Support new feature
  • Added unit tests
  • Edge case support (expanded values for when the next goes over the max value - or prev goes under the min)
  • Documentation

@kiorky
Copy link
Owner

kiorky commented Jul 12, 2024

I do not reproduce your bug.

>>> iter = croniter.croniter('0 0 */7 * *', datetime.datetime(2024,3,3)); pprint([iter.get_next(datetime.datetime) for i in range(3)])
[datetime.datetime(2024, 3, 8, 0, 0),
datetime.datetime(2024, 3, 15, 0, 0),
datetime.datetime(2024, 3, 22, 0, 0)]

@kiorky
Copy link
Owner

kiorky commented Jul 12, 2024

(and even with currentDate+afewdays)

>>> iter = croniter.croniter('0 0 */7 * *', datetime.datetime.now()); pprint([iter.get_next(datetime.datetime) for i in range(3)])
[datetime.datetime(2024, 7, 15, 0, 0),
 datetime.datetime(2024, 7, 22, 0, 0),
 datetime.datetime(2024, 7, 29, 0, 0)]
>>> iter = croniter.croniter('0 0 */7 * *', datetime.datetime.now()+datetime.timedelta(days=4)); pprint([iter.get_next(datetime.datetime) for i in range(3)])
[datetime.datetime(2024, 7, 22, 0, 0),
 datetime.datetime(2024, 7, 29, 0, 0),
 datetime.datetime(2024, 8, 1, 0, 0)]

@mghextreme
Copy link
Contributor Author

I do not reproduce your bug.

>>> iter = croniter.croniter('0 0 */7 * *', datetime.datetime(2024,3,3)); pprint([iter.get_next(datetime.datetime) for i in range(3)])
[datetime.datetime(2024, 3, 8, 0, 0),
datetime.datetime(2024, 3, 15, 0, 0),
datetime.datetime(2024, 3, 22, 0, 0)]

What I'm proposing it's not a bugfix.

In your example, you use the cron '0 0 */7 * *', means every 7 days.
But, by setting start_time as 2024-03-03, the next generated time is 2024-03-08 (5 days later, not 7).

By using the parameter I proposed it would still consider a 7 day gap. So instead of 2024-03-08 it would return 2024-03-10 (7 days later, same interval as the cron string).

@kiorky
Copy link
Owner

kiorky commented Jul 15, 2024

Ok, i better understand.
Why not, but please remove typing and non py2 compatible code as i still want to maintain this compat.

@kiorky
Copy link
Owner

kiorky commented Jul 16, 2024

i manually merged your commits and made the neccessary changes, thx !

@kiorky kiorky closed this Jul 16, 2024
@kiorky
Copy link
Owner

kiorky commented Jul 16, 2024

released as 2.0.6

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants