8.3. Date/Time Expressions

⁠8.3. Date/Time Expressions

Date/time expressions are rule conditions based (as the name suggests) on the current date and time.

A date_expression element may optionally contain a date_spec or duration element depending on the context.

Table 8.4. Attributes of a date_expression Element

Field	Description
`id`	A unique name for the expression (required)
`start`	A date/time conforming to the ISO8601 specification. May be used when `operation` is `in_range` (in which case at least one of `start` or `end` must be specified) or `gt` (in which case `start` is required).
`end`	A date/time conforming to the ISO8601 specification. May be used when `operation` is `in_range` (in which case at least one of `start` or `end` must be specified) or `lt` (in which case `end` is required).
`operation`	Compares the current date/time with the start and/or end date, depending on the context. Allowed values: `gt:` True if the current date/time is after `start` `lt:` True if the current date/time is before `end` `in_range:` True if the current date/time is after `start` (if specified) and before either `end` (if specified) or `start` plus the value of the `duration` element (if one is contained in the `date_expression`) `date_spec:` True if the current date/time matches the specification given in the contained `date_spec` element (described below)

Note

There is no eq, neq, gte, or lte operation, since they would be valid only for a single second.

⁠8.3.1. Date Specifications

A date_spec element is used to create a cron-like expression relating to time. Each field can contain a single number or range. Any field not supplied is ignored.

⁠

Table 8.5. Attributes of a date_spec Element

Field	Description
`id`	A unique name for the object (required)
`hours`	Allowed values: 0-23 (where 0 is midnight and 23 is 11 p.m.)
`monthdays`	Allowed values: 1-31 (depending on month and year)
`weekdays`	Allowed values: 1-7 (where 1 is Monday and 7 is Sunday)
`yeardays`	Allowed values: 1-366 (depending on the year)
`months`	Allowed values: 1-12
`weeks`	Allowed values: 1-53 (depending on weekyear)
`years`	Year according to the Gregorian calendar
`weekyears`	Year in which the week started; for example, 1 January 2005 can be specified in ISO 8601 as 2005-001 Ordinal, 2005-01-01 Gregorian or 2004-W53-6 Weekly and thus would match `years="2005"` or `weekyears="2004"`
`moon`	Allowed values are 0-7 (where 0 is the new moon and 4 is full moon). Seriously, you can use this. This was implemented to demonstrate the ease with which new comparisons could be added.

For example, monthdays="1" matches the first day of every month, and hours="09-17" matches the hours between 9 a.m. and 5 p.m. (inclusive).

At this time, multiple ranges (e.g. weekdays="1,2" or weekdays="1-2,5-6") are not supported.

Note

Pacemaker can calculate when evaluation of a date_expression with an operation of gt, lt, or in_range will next change, and schedule a cluster re-check for that time. However, it does not do this for date_spec. Instead, it evaluates the date_spec whenever a cluster re-check naturally happens via a cluster event or the cluster-recheck-interval cluster option. For example, if you have a date_spec enabling a resource from 9 a.m. to 5 p.m., and cluster-recheck-interval has been set to 5 minutes, then sometime between 9 a.m. and 9:05 a.m. the cluster would notice that it needs to start the resource, and sometime between 5 p.m. and 5:05 p.m. it would realize that it needs to stop the resource. The timing of the actual start and stop actions will further depend on factors such as any other actions the cluster may need to perform first, and the load of the machine.