Calendars
A calendar 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 appointments 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 visualisation 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 a definition of which days are weekends (Saturday and Sunday by default). That baseline is what applies to every date unless something more specific overrides it.
On top of that baseline you can add four 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."
- Day overrides can also flip the opposite direction: a working day that would normally be closed (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 stabilise 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 child calendar's overrides do not get "promoted" because they came from a parent - the override type alone decides priority.
Inheriting one calendar from another
Most organisations 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 not inherited, because the child defines its own. There is no limit on nesting depth, and a child can itself be the parent of another calendar.
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. Open the resource calendars section, click Add, then pick the resource, the alternative calendar, and the date range it applies for (the "until" date is exclusive). You can stack multiple period-specific calendars for the same resource without conflicts.
Working with the calendar view
The grid in the middle of the screen shows the calendar day by day, with colors explained in the legend on the right. Edits are not saved automatically: after changing any setting, click the sync button. If you navigate away without syncing, your changes are lost.
To create a calendar, click Add, give it a code (any internal reference) and a name. Check default to make it the company's standard calendar on the planning board.
Reference
General settings
| Setting | Description |
|---|---|
| Weekends are work days | When checked, weekends will not be marked as non-working time |
| Weekend first day | Determines the first weekend day in your company (by default Saturday) |
| Weekend second day | Determines the second weekend day in your company (by default Sunday) |
| Days per month | This will not affect the actual days per month but is used to convert units of measure in the Gantt charts. E.g. when inserting 1 month for a Task duration a conversion is done to the corresponding number of days inserted in this field. |
| Days per week | This will not affect the actual days per week but is used to convert units of measure in the Gantt charts. E.g. when inserting 1 week for a Task duration a conversion is done to the corresponding number of days inserted in this field. |
| Hours per day | This will not affect the actual hours per day but is used to convert units of measure in the Gantt charts. E.g. when inserting 1 day for a Task duration a conversion is done to the corresponding number of hours inserted in this field. |
Override types
- Business hours. Any number of time slots that count as working time on a normal day.
- Day override. A single date (e.g. May 23rd 2019), marked as non-working, working with custom hours, or default.
- Week day. A recurring day of the week (e.g. all Mondays), useful for patterns like an early Friday finish.
- Week override. A non-standard week within a date range. A week override is only saved when at least one day inside it is non-standard - otherwise it would have no effect.