Trigger alias for
CronTrigger(year=None, month=None, day=None, week=None, day_of_week=None, hour=None, minute=None, second=None, start_date=None, end_date=None, timezone=None, jitter=None)¶
Triggers when current time matches all specified time constraints, similarly to how the UNIX cron scheduler works.
- year (int|str) – 4-digit year
- month (int|str) – month (1-12)
- day (int|str) – day of the (1-31)
- week (int|str) – ISO week (1-53)
- day_of_week (int|str) – number or name of weekday (0-6 or mon,tue,wed,thu,fri,sat,sun)
- hour (int|str) – hour (0-23)
- minute (int|str) – minute (0-59)
- second (int|str) – second (0-59)
- start_date (datetime|str) – earliest possible date/time to trigger on (inclusive)
- end_date (datetime|str) – latest possible date/time to trigger on (inclusive)
- timezone (datetime.tzinfo|str) – time zone to use for the date/time calculations (defaults to scheduler timezone)
- jitter (int|None) – advance or delay the job execution by
jitterseconds at most.
The first weekday is always monday.
This is the most powerful of the built-in triggers in APScheduler. You can specify a variety of different expressions on each field, and when determining the next execution time, it finds the earliest possible time that satisfies the conditions in every field. This behavior resembles the “Cron” utility found in most UNIX-like operating systems.
You can also specify the starting date and ending dates for the cron-style schedule through the
end_date parameters, respectively. They can be given as a date/datetime object or text (in the
ISO 8601 format).
Unlike with crontab expressions, you can omit fields that you don’t need. Fields greater than the least significant
explicitly defined field default to
* while lesser fields default to their minimum values except for
day_of_week which default to
*. For example,
day=1, minute=20 is equivalent to
year='*', month='*', day=1, week='*', day_of_week='*', hour='*', minute=20, second=0. The job will then execute
on the first day of every month on every year at 20 minutes of every hour. The code examples below should further
illustrate this behavior.
The behavior for omitted fields was changed in APScheduler 2.0.
Omitted fields previously always defaulted to
The following table lists all the available expressions for use in the fields from year to second. Multiple expression can be given in a single field, separated by commas.
||any||Fire on every value|
||any||Fire on any value within the
||day||Fire on the
||day||Fire on the last occurrence of weekday
||day||Fire on the last day within the month|
||any||Fire on any matching expression; can combine any number of any of the above expressions|
day_of_week fields accept abbreviated English month and weekday names
Daylight saving time behavior¶
The cron trigger works with the so-called “wall clock” time. Thus, if the selected time zone observes DST (daylight saving time), you should be aware that it may cause unexpected behavior with the cron trigger when entering or leaving DST. When switching from standard time to daylight saving time, clocks are moved either one hour or half an hour forward, depending on the time zone. Likewise, when switching back to standard time, clocks are moved one hour or half an hour backward. This will cause some time periods to either not exist at all, or be repeated. If your schedule would have the job executed on either one of these periods, it may execute more often or less often than expected. This is not a bug. If you wish to avoid this, either use a timezone that does not observe DST, for instance UTC. Alternatively, just find out about the DST switch times and avoid them in your scheduling.
For example, the following schedule may be problematic:
# In the Europe/Helsinki timezone, this will not execute at all on the last sunday morning of March # Likewise, it will execute twice on the last sunday morning of October sched.add_job(job_function, 'cron', hour=3, minute=30)
from apscheduler.schedulers.blocking import BlockingScheduler def job_function(): print "Hello World" sched = BlockingScheduler() # Schedules job_function to be run on the third Friday # of June, July, August, November and December at 00:00, 01:00, 02:00 and 03:00 sched.add_job(job_function, 'cron', month='6-8,11-12', day='3rd fri', hour='0-3') sched.start()
You can use
end_date to limit the total time in which the schedule runs:
# Runs from Monday to Friday at 5:30 (am) until 2014-05-30 00:00:00 sched.add_job(job_function, 'cron', day_of_week='mon-fri', hour=5, minute=30, end_date='2014-05-30')
scheduled_job() decorator works nicely too:
@sched.scheduled_job('cron', id='my_job_id', day='last sun') def some_decorated_task(): print("I am printed at 00:00:00 on the last Sunday of every month!")
To schedule a job using a standard crontab expression:
sched.add_job(job_function, CronTrigger.from_crontab('0 0 1-15 may-aug *'))
jitter option enables you to add a random component to the execution time. This might be useful if you have
multiple servers and don’t want them to run a job at the exact same moment or if you want to prevent jobs from running
at sharp hours:
# Run the `job_function` every sharp hour with an extra-delay picked randomly in a [-120,+120] seconds window. sched.add_job(job_function, 'cron', hour='*', jitter=120)