Calendars
A calendarCalendarA definition of when work can happen, for the whole tenant or for specific resources: business hours, weekends and holidays. Calendars shade non-working time on the planning board and skip it in Gantt durations. describes when work can happen: regular business hours, weekends, holidays, the occasional shorter Friday. Calendars are how Dime.Scheduler knows the difference between a normal Tuesday and Christmas Day, between a 9-to-5 office and a 24/7 crew.
Without calendars, the planning board treats every hour the same. Planners can drop appointmentsAppointmentA task scheduled to a resource for a specific period - the scheduled instance you see on the planning board. on public holidays without warning, overtime hides instead of standing out, and Gantt chart durations are off because the system has no way to know which days actually count as working days. The calendar setup page is where you give Dime.Scheduler that ground truth - once per tenant for the default working pattern, and as many extra calendars as you need for teams or resources that work differently.
When the calendar visualization is enabled in Administration > Application > Planning, Dime.Scheduler shades non-working time on the planning boardPlanning boardThe main graphical scheduling surface where dispatchers drag tasks onto resources across a timeline. so planners stay inside business hours by default. The same calendars drive Gantt charts, where non-working time is rendered as gaps and taskTaskA unit of work that belongs to a job. It appears in the open task list until it is scheduled to a resource. duration is recalculated to skip them.
How a calendar is built
Every calendar starts from the same baseline: a set of Business Hours (the time slots that count as working time, for example 08:00-12:00 and 13:00-17:00) and the weekend, Saturday and Sunday, which is non-working unless you tick Weekends are work days. That baseline is what applies to every date unless something more specific overrides it.
On top of that baseline you can add three kinds of overrides, each more specific than the last:
- Week days recur every week, like "Fridays we leave at 16:00."
- Week overrides apply a non-standard week within a date range, like "Last week of June, Saturday is a working day."
- Day overrides target a single date, like "December 25th, closed." They work in the other direction too: a day that would normally be closed can be made a working day with its own hours (a Saturday open-house, for example).
You will usually start by defining the company baseline once, then layer overrides as the exceptions come up. Most setups stabilize quickly; the calendar is something you touch when the holiday list rolls over, not a daily concern.
How conflicts resolve
The interesting question is what happens when two rules apply to the same date. Day overrides win over week overrides, week overrides win over week days, and the baseline (business hours + weekends) loses to all three. In short: the more specific the override, the higher its priority.
To make this concrete, take a calendar with:
| Description | Value |
|---|---|
| Business hours | 08:00-12:00 and 13:00-18:00 |
| Weekend | Saturday and Sunday |
| Day overrides | December 25th and January 1st |
| Week overrides | Between June 28th and July 5th:
|
| Week days | Fridays are working days between 08:00-12:00 and 13:00-17:00 |
Walk through the conflicts:
- Friday the 3rd of July. The week override beats the week day, so employees work 08:00-12:00 and 13:00-18:00, not the early-finish Friday.
- Saturday the 4th of July. Normally non-working, but the week override pulls it in: 08:00-12:00 and 13:00-15:00.
- Friday the 25th of December. Day override beats everything below it, so nobody works.
- Wednesday the 1st of January. Day override marks it non-working. No conflict to resolve.
- Thursday the 2nd of January. No overrides apply, so the baseline takes over: 08:00-12:00 and 13:00-17:00.
The hierarchy is unchanged by inheritance (covered next). A calendar's overrides do not get "promoted" because they came from a parent: the override type decides priority first. Only when two rules of the same type apply to the same date does the calendar they belong to matter, and then the calendar's own rule beats its parent's, which beats the grandparent's. Should a working and a non-working rule of the same type on the same calendar both claim a date, they cancel each other out and the baseline decides.
A working override that carries no hours of its own takes the calendar's business hours, including hours the calendar inherits from a parent.
Inheriting one calendar from another
Most organizations end up with a small set of calendars that mostly look alike: the company baseline, then a couple of variations for regional offices or specific teams. Rather than maintaining each one from scratch, you can mark a calendar as a child of another and override only what differs.
.
+-- Base calendar
| +-- Business hours
| +-- 08:00 - 12:00
| +-- 13:00 - 17:00
| +-- Holidays
| +-- December 25th
| +-- January 1st
| +-- May 1st
| +-- Child calendars
| +-- Region EAST calendar
| +-- Business hours
| +-- 09:00 - 13:00
| +-- 14:00 - 18:00
| +-- Holidays
| +-- June 25th
| +-- March 3rd
+-- Unrelated calendar
| +-- Business hours
| +-- 22:00 - 02:00
| +-- 04:00 - 08:00
| +-- Holidays
| +-- November 11th
| +-- May 30th
| +-- February 29th
In this example the "Region EAST" calendar inherits from "Base calendar," so the parent's holidays (December 25th, January 1st, May 1st) apply to Region EAST too. Business hours are inherited as well, as a single block: a child that defines no hours of its own uses the parent's, and a child that defines any uses only its own, which is why Region EAST works 09:00-13:00 and 14:00-18:00 rather than the base hours. There is no limit on nesting depth, and a child can itself be the parent of another calendar.
On screen, everything a calendar gets from its ancestors is marked. Inherited business hours show a banner reading Inherited from the parent, with an Override from button that copies the parent's hours onto the child as a starting point for editing. Inherited overrides appear in the grids greyed out, with the owning calendar named, and cannot be edited or removed from the child; edit them on the parent, or add the child's own override for the same date, which then wins. Inherited week overrides stay in play next to the child's own, even when both cover the same dates. On a given day the child's week override wins if it has a tile for that weekday; where it leaves the weekday at default, the parent's week override still applies. The month view resolves every date this way, so it shows exactly what the planning board will use, and clicking a date selects the override that actually decides it.
There are two ways to set the parent. The Parent calendar dropdown in the settings section lists every calendar that is not the current one or one of its descendants. Or drag a calendar onto another one in the tree on the left; a drop zone at the bottom of the tree detaches it again. Either way the change is staged until you save.
Working with the page
The tree on the left lists the calendars. Add creates one, prefilled with a placeholder name and code and a standard 08:00-16:00 working day; the first calendar you ever create is automatically the default. The remove button next to it deletes the selected calendar after confirmation, and is hidden for the default calendar. The tree can be collapsed to a narrow rail when you need the room.
Selecting a calendar fills the rest of the screen with its sections, top to bottom: Settings (name, code, parent, whether it is the default, and whether weekends count as work days), Business Hours, Day overrides, Week overrides and Week days. The month view on the right shows the net result for any month, with a legend for working days, non-working days and the three override types. Right-click a date there to create a day, week day or week override starting from that date, which is faster than scrolling to the right section.
Editing a day or a week
Day overrides and week days share an editor: a name, a Working day toggle, and, for working days, up to five time intervals. The editor refuses intervals that end before they start or overlap one another, because either would make the day's working time ambiguous.
A week override has a name and a date range, then one tile per weekday. Each tile is either left at Default time, meaning the calendar's normal rule applies, or opened in the day editor to become a working or non-working day with its own hours. A week where every tile is still at default would change nothing, so it cannot be saved.
Saving
Edits are not saved automatically. As soon as something changes, a bar appears at the top of the page saying You have unsaved changes and listing what changed, with Discard and Save buttons. Ctrl+S (Cmd+S on a Mac) saves as well. Selecting another calendar while there are unsaved changes asks whether to discard them first, so you cannot lose work by clicking around.
Saving checks a few things before it writes, and refuses with a message if one fails: a calendar must have both a name and a code, the tenant must keep at least one default calendar, business-hour intervals must not overlap or be inverted, a date can carry only one day override, and week override date ranges cannot overlap each other. Each of these protects against a calendar that the planning board could not interpret unambiguously.
Giving a specific resource its own calendar
Sometimes a single resource needs to follow a different schedule for a period - a part-time contract, a temporary assignment in another region, a sabbatical. The Resource calendars page, reached from the rail on the far left, links a resourceResourceAn entity that can carry out work - a person, vehicle, tool, or room - that you schedule on the planning board. to a calendar for a date range.
Add links one resource: pick the resource, the calendar, a start date and an end date. Both dates are required and both are included, so a link that ends on Friday still covers that Friday. For a link that should run indefinitely, pick an end date far in the future. You can stack several period-specific calendars for the same resource.
Bulk add does the same for many resources at once, which is what you want when a whole crew moves to a summer schedule. Pick the calendar, click and drag on the date picker to select the range, then tick resources in the grid. The grid is searchable and filterable on name, number, type and team, and a counter keeps track of how many are selected. Skip duplicates is on by default: resources already linked to that calendar in the chosen period are left alone, and the dialog tells you how many will be skipped before you create the entries. The dialog can be maximized when the resource list is long.
The grid of existing links can be viewed as a flat list (All) or narrowed to one month (Month), with previous and next arrows and a Today button to move around. Rows are edited from the pencil icon and removed from the trash icon, the Remove button for a multi-selection, or the Delete key.