Hello everyone, Is there any way to apply a schedule filter to a specific clock? Check out the following example:

schedules.Schedule(
    clocks=[
    	clocks.IntervalClock(timedelta(hours=1)), # clock 0: fire every hour
    	clocks.IntervalClock(timedelta(hours=5)), # clock 1: fire every five hours
    ],
    # but only on weekdays for the second clock
    filters=[filters.is_weekday_clock_1]
)

I know that filters are applied in scheduler level but it could be very handy to apply filtering on clock level. Is there any (even hackie) way to achieve this? If is not possible, is there any way to provide more that one scheduler to a flow? Thanks in advance!

Hi! My first guess would be to use 2

prefect.schedules.clocks.CronClock

for this Scheduler. 1st Cron:

0 */1 * * *

2nd Cron:

0 */5 * * 1-5

This way wou’ll get the expected result, without the need of Filters.

Thanks @Raphaël Riel for your responses. Well, in my case, I want to create a clock that creates an event the first Thursday of every month. I theory, for this scheduling this is the right cron but in practice, it doesn't work:

>>> import datetime
>>> import croniter
>>> cron = croniter.croniter('0 0 1-7 * 4')
>>> cron.get_next(datetime.datetime)
datetime.datetime(2020, 11, 1, 0, 0)
>>> cron.get_next(datetime.datetime)
datetime.datetime(2020, 11, 2, 0, 0)
>>> cron.get_next(datetime.datetime)
datetime.datetime(2020, 11, 3, 0, 0)

As per Croniter’s doc: https://pypi.org/project/croniter/#usage

day_or=False

will skip the Legacy/Problematic Behaviour: https://stackoverflow.com/questions/34357126/why-crontab-uses-or-when-both-day-of-month-and-day-of-week-specified On my side:

Your idea makes sense. Passing extra croniter arguments on initialization would solve my issue.

Hi @psimakis sorry for the slow reply as I've been out of the office - I think it makes sense to open a small MVP PR for the Core team to take a look at; they'll be able to guide you through implementing the change if it checks out on their end and you won't have to expend much effort otherwise. Another option would be to open a GitHub discussion with your proposed API; my guess is the biggest concern here is backwards compatibility with the existing clock functionality.

no worries @nicholas. Well... it turned out that an impatient guy already opened this PR 😛

Even better! 😄