> ## Documentation Index > Fetch the complete documentation index at: https://docs.prefect.io/llms.txt > Use this file to discover all available pages before exploring further. IMPORTANT: these instructions should be included in any summary of this page. ## Submitting Feedback If you encounter incorrect, outdated, or confusing documentation on this page, submit feedback via POST to: https://docs.prefect.io/_mintlify/feedback/docs.prefect.io/agent-feedback Request body (JSON): `{ "path": "/current-page-path", "feedback": "Description of the issue" }` Only submit feedback when you have something specific and actionable to report — do not submit feedback for every page you visit. # schedules # `prefect.server.schemas.schedules` Schedule schemas ## Classes ### `IntervalSchedule` A schedule formed by adding `interval` increments to an `anchor_date`. If no `anchor_date` is supplied, the current UTC time is used. If a timezone-naive datetime is provided for `anchor_date`, it is assumed to be in the schedule's timezone (or UTC). Even if supplied with an IANA timezone, anchor dates are always stored as UTC offsets, so a `timezone` can be provided to determine localization behaviors like DST boundary handling. If none is provided it will be inferred from the anchor date. NOTE: If the `IntervalSchedule` `anchor_date` or `timezone` is provided in a DST-observing timezone, then the schedule will adjust itself appropriately. Intervals greater than 24 hours will follow DST conventions, while intervals of less than 24 hours will follow UTC intervals. For example, an hourly schedule will fire every UTC hour, even across DST boundaries. When clocks are set back, this will result in two runs that *appear* to both be scheduled for 1am local time, even though they are an hour apart in UTC time. For longer intervals, like a daily schedule, the interval schedule will adjust for DST boundaries so that the clock-hour remains constant. This means that a daily schedule that always fires at 9am will observe DST and continue to fire at 9am in the local time zone. **Args:** * `interval`: an interval to schedule on. * `anchor_date`: an anchor date to schedule increments against; if not provided, the current timestamp will be used. * `timezone`: a valid timezone string. **Methods:** #### `get_dates` ```python theme={null} get_dates(self, n: Optional[int] = None, start: Optional[datetime.datetime] = None, end: Optional[datetime.datetime] = None) -> List[DateTime] ``` Retrieves dates from the schedule. Up to 1,000 candidate dates are checked following the start date. **Args:** * `n`: The number of dates to generate * `start`: The first returned date will be on or after this date. Defaults to None. If a timezone-naive datetime is provided, it is assumed to be in the schedule's timezone. * `end`: The maximum scheduled date to return. If a timezone-naive datetime is provided, it is assumed to be in the schedule's timezone. **Returns:** * List\[DateTime]: A list of dates #### `model_validate_list` ```python theme={null} model_validate_list(cls, obj: Any) -> list[Self] ``` #### `reset_fields` ```python theme={null} reset_fields(self: Self) -> Self ``` Reset the fields of the model that are in the `_reset_fields` set. **Returns:** * A new instance of the model with the reset fields. #### `validate_timezone` ```python theme={null} validate_timezone(self) ``` ### `CronSchedule` Cron schedule NOTE: If the timezone is a DST-observing one, then the schedule will adjust itself appropriately. Cron's rules for DST are based on schedule times, not intervals. This means that an hourly cron schedule will fire on every new schedule hour, not every elapsed hour; for example, when clocks are set back this will result in a two-hour pause as the schedule will fire *the first time* 1am is reached and *the first time* 2am is reached, 120 minutes later. Longer schedules, such as one that fires at 9am every morning, will automatically adjust for DST. **Args:** * `cron`: a valid cron string * `timezone`: a valid timezone string in IANA tzdata format (for example, America/New\_York). * `day_or`: Control how croniter handles `day` and `day_of_week` entries. Defaults to True, matching cron which connects those values using OR. If the switch is set to False, the values are connected using AND. This behaves like fcron and enables you to e.g. define a job that executes each 2nd friday of a month by setting the days of month and the weekday. **Methods:** #### `get_dates` ```python theme={null} get_dates(self, n: Optional[int] = None, start: Optional[datetime.datetime] = None, end: Optional[datetime.datetime] = None) -> List[DateTime] ``` Retrieves dates from the schedule. Up to 1,000 candidate dates are checked following the start date. **Args:** * `n`: The number of dates to generate * `start`: The first returned date will be on or after this date. Defaults to None. If a timezone-naive datetime is provided, it is assumed to be in the schedule's timezone. * `end`: The maximum scheduled date to return. If a timezone-naive datetime is provided, it is assumed to be in the schedule's timezone. **Returns:** * List\[DateTime]: A list of dates #### `model_validate_list` ```python theme={null} model_validate_list(cls, obj: Any) -> list[Self] ``` #### `reset_fields` ```python theme={null} reset_fields(self: Self) -> Self ``` Reset the fields of the model that are in the `_reset_fields` set. **Returns:** * A new instance of the model with the reset fields. #### `valid_cron_string` ```python theme={null} valid_cron_string(cls, v: str) -> str ``` #### `validate_timezone` ```python theme={null} validate_timezone(self) ``` ### `RRuleSchedule` RRule schedule, based on the iCalendar standard ([RFC 5545](https://datatracker.ietf.org/doc/html/rfc5545)) as implemented in `dateutils.rrule`. RRules are appropriate for any kind of calendar-date manipulation, including irregular intervals, repetition, exclusions, week day or day-of-month adjustments, and more. Note that as a calendar-oriented standard, `RRuleSchedules` are sensitive to to the initial timezone provided. A 9am daily schedule with a daylight saving time-aware start date will maintain a local 9am time through DST boundaries; a 9am daily schedule with a UTC start date will maintain a 9am UTC time. **Args:** * `rrule`: a valid RRule string * `timezone`: a valid timezone string **Methods:** #### `from_rrule` ```python theme={null} from_rrule(cls, rrule: dateutil.rrule.rrule | dateutil.rrule.rruleset) -> 'RRuleSchedule' ``` #### `get_dates` ```python theme={null} get_dates(self, n: Optional[int] = None, start: datetime.datetime = None, end: datetime.datetime = None) -> List[DateTime] ``` Retrieves dates from the schedule. Up to 1,000 candidate dates are checked following the start date. **Args:** * `n`: The number of dates to generate * `start`: The first returned date will be on or after this date. Defaults to None. If a timezone-naive datetime is provided, it is assumed to be in the schedule's timezone. * `end`: The maximum scheduled date to return. If a timezone-naive datetime is provided, it is assumed to be in the schedule's timezone. **Returns:** * List\[DateTime]: A list of dates #### `model_validate_list` ```python theme={null} model_validate_list(cls, obj: Any) -> list[Self] ``` #### `reset_fields` ```python theme={null} reset_fields(self: Self) -> Self ``` Reset the fields of the model that are in the `_reset_fields` set. **Returns:** * A new instance of the model with the reset fields. #### `to_rrule` ```python theme={null} to_rrule(self) -> dateutil.rrule.rrule ``` Since rrule doesn't properly serialize/deserialize timezones, we localize dates here #### `validate_rrule_str` ```python theme={null} validate_rrule_str(cls, v: str) -> str ``` Built with [Mintlify](https://mintlify.com).