Skip to content

Support expand_from_start_time#76

Closed
mghextreme wants to merge 1 commit intopallets-eco:masterfrom
mghextreme:master
Closed

Support expand_from_start_time#76
mghextreme wants to merge 1 commit intopallets-eco:masterfrom
mghextreme:master

Conversation

@mghextreme
Copy link
Contributor

@mghextreme mghextreme commented Jul 11, 2024

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
Collaborator

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
Collaborator

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

mghextreme 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)]

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
Collaborator

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
Collaborator

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
Collaborator

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

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@mghextreme @kiorky