Capacity blocks are the main building blocks for scheduling time for the organization.

1. Capacity blocks can be scheduled at an organization level, a resource group level, or resource level.
   1. In order to add a capacity block to an organization, select the “Organization” tab.
   2. In order to add a capacity block to a resource group, select the “Resource Groups” tab, select the resource group you want to add capacity to, and navigate to the “Capacity Schedule” tab.
   3. In order to add a capacity block to a resource, select the “Resources” tab, select the resource you want to add capacity to, and navigate to the “Capacity Schedule” tab.
2. Capacity blocks can be added through the calendar component of the resource management app on the “Capacity Schedule” tabs.
   1. Select the time that you want to schedule your capacity block.
   2. Once selected, a window will open with options to configure your capacity block.
   3. Users have the ability to
      1. Add a name for your capacity block.
      2. Select a “Downtime” or “Uptime” for each capacity block.
      3. If adding a capacity block to a resource group, users have the ability to select which resource group they want the capacity block assigned to.
   4. Users can also select “Advanced Settings” in order to specifically
      1. Edit the capacity block using a cron expression.
      2. Schedule the capacity block to be an all-day event.
      3. Configure that if an uptime block overlaps with a downtime block, it can override the downtime block.
      4. Select the repetitiveness of the capacity blocks on a designated schedule.
3. Capacity blocks can also be added by selecting either the “Add Uptime” or “Add Downtime” options on the capacity blocks table.

Cron Expressions

Capacity blocks use a modified cron syntax to store recurring blocks. Capacity blocks within resource management can be configured manually or through cron expressions. For advanced logic not achievable with the user interface, you can manually enter a cron expression.

By default, cron syntax is 5 or 6 fields separated by spaces. The fields are as follows:

# ┌───────────── second (0 - 59) (optional, missing for 5 fields)
# │ ┌───────────── minute (0 - 59)
# │ │ ┌───────────── hour (0 - 23)
# │ │ │ ┌───────────── day of the month (1 - 31)
# │ │ │ │ ┌───────────── month (1 - 12)
# │ │ │ │ │ ┌───────────── day of the week (0 - 6) (Sunday to Saturday)
# │ │ │ │ │ │
# │ │ │ │ │ │
# * * * * * *

Any 5 or 6 field expressions will be resolved with this logic. We have extended this syntax to include three more fields, any expression in excess of 6 fields:

# ┌───────────── year (1 - infinity)
# │ ┌───────────── days since epoch (0 - infinity) (0 = 1-Jan-1970)
# │ │ ┌───────────── months since epoch (1 - infinity) (1 = Jan 1970)
# │ │ │
# │ │ │
# * * *

The “year” field allows us to specify one-off events in cron, and every X years events. The “days/months since epoch” field allow us to specify every X days. Using some operations, we can make weeks since epoch, using grouping in cron.

Calculating days since epoch

The millisecond timestamp for the start of 1.1.1970 in the local timezone will be marked as localEpoch. This is not necessarily 0 in the unix epoch, due to timezones. For the moment of time we’re observing, labeled target, let us keep the date part, and replace the time part with noon. This way we have some leeway when calculating the timestamp delta, as DST switches can mess with exact alignment.

Logic:

const MILLIS_IN_DAY = 24 * 3600 * 1000;
const targetTimestamp = target.set({ hour:12, minute:0, second: 0, millisecond: 0}).toMillis();
const daysPassed = Math.floor((targetTimestamp - localEpoch) / MILLIS_IN_DAY);

Value groups

Assuming we mark literal values with V1 and V2, and step with S, the following are valid cron values:

• V1 - that literal value

• V1-V2 - all literal values in the given range, inclusively

• V1-V2/S - similar to above, but we move with a step of S; So 2-9/3 would cover 2,5,8

• • • all legal values, equivalent to minValue-maxValue
• */S - starting from the minimum legal value, with a step of S

The values can be comma separated, representing a union between the queries. A new shape we are adding is V1/S, where we start V1 and iterate with a step through all legal values. It is equivalent to V1-maxValue/S. This allows for expressing a starting point for infinite ranges, like years or days and months since epoch, while still working correctly for other fields too. We have additionally added negative numbers, allowing you to specify things starting from the highest legal value. This is most relevant for end of the month behavior, but can be a convenient syntax for situations as well. For example, a cron of 0 0 12 -2 * * will trigger at noon of the second last day of the month - Jan 30th, Feb 27th (for non-leap years, 28th on leap years), Mar 30th, Apr 29th, etc.

Reference: example default cron expressions.