Primavera P6 allows every activity to carry its own calendar and also every relationship lag to be evaluated against a different one. When your schedule mixes five-day, six-day, seven-day and shift calendars, the CPM (Critical Path Method) dates that come out are only correct if you understand which calendar P6 is using at each step of the calculation. Here we explain the rules.
How Calendars Are Assigned in P6
Every activity in P6 is assigned a calendar that defines its working days and hours. This calendar controls two things: how the activity’s duration is counted (only working days/hours accumulate) and on which days the activity is permitted to start and finish.
P6 supports three types of calendars: Global calendars (available to all projects), Project calendars (specific to one project) and Resource calendars (assigned to resources rather than activities). For CPM date calculations, it is the activity calendar and the relationship lag calendar that matter.
By default, P6 assigns the project’s default calendar to every new activity. You can override this at the activity level in the General tab of the Activity Details pane.
How P6 Counts Duration Across a Calendar
When P6 computes an Early Finish from an Early Start and a duration, it counts only working periods on the activity’s assigned calendar. Non-working days (weekends, holidays, shutdowns) are skipped entirely.
| EARLY FINISH CALCULATION EF = ES + Duration (working days on activity calendar) – 1 |
A 5-day activity starting on a Monday with a standard Mon–Fri calendar finishes on Friday. The same 5-day activity on a 7-day calendar finishes on Friday of the same week too. But if it started on Thursday, it would finish on Monday rather than the following Wednesday, because Saturday and Sunday are working days on the 7-day calendar.
KEY RULE – DURATION IS CALENDAR-DEPENDENT The same numeric duration produces different calendar-day spans depending on the activity calendar. A 10-day duration on a 5-day calendar spans 2 calendar weeks. The same 10-day duration on a 7-day calendar spans 10 consecutive calendar days. Never compare durations across activities on different calendars without accounting for this.
Which Calendar Governs Relationship Lag?
This is the most commonly misunderstood aspect of multi-calendar scheduling in P6. When a lag is applied to a relationship, P6 must decide which calendar to use to count those lag days. The answer depends on a Schedule Options setting, Tools | Schedule | Options | General > Calendar for scheduling Relationship Lag.
| Setting | Calendar Used for Lag | Implication |
| Use Predecessor Activity Calendar (default off) | Predecessor’s calendar | Lag counts on the predecessor’s working days |
| Use Successor Activity Calendar (default on) | Successor’s calendar | Lag counts on the successor’s working days |
| 24 Hour Calendar | A calendar where every day is 24 hours | Good to schedule 24-h-per-day processes like curing. |
| Project Default Calendar | The default calendar assigned in Projects | Defaults > Calendar | Lag counts on the database’s default calendar. |
The default in most P6 installations is to use the successor’s calendar for lag. This means that a 5-day lag on an FS relationship will be counted as 5 working days on whatever calendar the successor activity is assigned to, regardless of the predecessor’s calendar.
VERIFY YOUR ADMIN PREFERENCES The lag calendar setting is found in Tools | Schedule | Options | General > Calendar for scheduling Relationship Lag. This is a global setting that affects every project in the P6 database. If you are working in a shared enterprise environment, confirm this setting with your P6 administrator before relying on lag-driven dates.
The Forward Pass Across Different Calendars
When the predecessor and successor are on different calendars, P6 must translate the predecessor’s Early Finish (expressed on the predecessor’s calendar) into a valid Early Start on the successor’s calendar.
P6 does this by finding the next working moment on the successor’s calendar that falls on or after the predecessor’s Early Finish (plus any lag). If the predecessor finishes on a day that is non-working for the successor, P6 advances the successor’s Early Start to the next working day on the successor’s calendar.
Example: 5-day predecessor, 6-day successor
Activity A is on a Mon–Fri calendar and finishes on Friday (end of Day 5 of the week). Activity B is on a Mon–Sat calendar with an FS + 0 relationship. Saturday is a working day for B.
| Activity | Calendar | Early Finish / Early Start | Note |
| A | Mon–Fri | Friday | Last working day of A |
| B | Mon–Sat | Saturday | Saturday is a working day for B — P6 starts B immediately |
If instead, B were on a Mon–Fri calendar and A finished on Friday, B’s Early Start would be the following Monday — the next working day on B’s calendar.
Example: 5-day predecessor, 7-day successor
Activity A finishes on Friday. Activity B is on a 7-day calendar (all days working) with FS + 3 lag. The 3 lag days are counted on B’s calendar (7-day), meaning Saturday, Sunday and Monday are all working lag days.
| Step | Date | Detail |
| A finishes | Friday | EF (A) on Mon–Fri 5-day calendar |
| Lag Day 1 | Saturday | Working day on B’s 7-day calendar |
| Lag Day 2 | Sunday | Working day on B’s 7-day calendar |
| Lag Day 3 | Monday | Working day on B’s 7-day calendar |
| B starts | Tuesday | ES (B) — first day after lag expires |
If the lag were counted on A’s Mon–Fri calendar instead, Saturday and Sunday would not count as lag days, and B would not start until Thursday. The difference is two full calendar days. This is purely from the calendar setting in Admin Preferences.
The Backward Pass Across Different Calendars
In the backward pass, P6 works in reverse. It takes the successor’s Late Start and subtracts the relationship lag to derive the predecessor’s Late Finish. The lag is again counted on the governing lag calendar (successor by default).
After computing LF (A), P6 must ensure that the resulting date falls on a working day for the predecessor. If LF (A) lands on a non-working day for the predecessor, P6 moves it back to the most recent working day on the predecessor’s calendar.
WATCH OUT — CALENDAR ROUNDING DIRECTION In the forward pass, P6 rounds forward to the next working day when a date falls on a non-working period. In the backward pass, P6 rounds backward to the previous working day. This asymmetry is intentional and correct. But it does mean that activities on different calendars can appear to have float values that are slightly unexpected when you calculate them manually. Always let P6 do the arithmetic rather than computing multi-calendar float by hand.
Float Across Multiple Calendars
Total Float in P6 is always expressed in the activity’s own calendar units. This creates an important comparability problem. A TF of 5 days on a 5-day calendar activity represents 7 calendar days of slack, while a TF of 5 days on a 7-day calendar activity represents exactly 5 calendar days of slack. The numbers look the same in the schedule but mean different things in real time.
| Activity | Calendar | Total Float (P6) | Equivalent Calendar Days |
| A | Mon–Fri (5-day) | 5 days | 7 calendar days (includes weekend) |
| B | 7-day | 5 days | 5 calendar days |
| C | Mon–Sat (6-day) | 5 days | 6 calendar days (includes Saturday) |
When reporting float to stakeholders across a multi-calendar schedule, consider converting float to calendar days for a consistent comparison. P6 does not do this conversion automatically in its standard columns.
The Critical Path in a Multi-Calendar Schedule
The critical path in P6 is defined as the chain of activities with zero total float. In a multi-calendar schedule, identifying the true critical path requires understanding that the longest path in working days may not be the longest path in calendar days.
A chain of 7-day calendar activities with zero float may complete in fewer calendar days than a chain of 5-day calendar activities with the same number of working-day durations. If your project deadline is a fixed calendar date, the critical path is the one that most constrains that calendar date. This may not always be the chain with the most working-day duration.
BEST PRACTICE – USE A SINGLE DOMINANT CALENDAR WHERE POSSIBLE Where project reporting is done against calendar dates (e.g. contractual milestones), consider applying the same baseline calendar to all summary-level activities and reserving different calendars for detailed work packages only. This makes float comparison and critical path reading significantly more reliable across reports.
Common Multi-Calendar Pitfalls in P6
- Lag calculated on the wrong calendar: a 10-day procurement lag may count as 10 Mon–Fri days or 10 seven-day days depending on the Schedule Options setting. Confirm before trusting lag-driven milestones.
- Successor starts on a non-working day: if P6 computes an Early Start that falls on a non-working day for the successor, it silently advances to the next working day. This can introduce unintentional float.
- Holiday exceptions on individual calendars: a public holiday added to one calendar but not another can move a critical activity’s dates by a day, shifting the critical path without any relationship change.
- Resource calendars vs activity calendars: if a resource is on a different calendar from its assigned activity, P6 may calculate resource availability differently from activity availability, producing levelling results that do not align with the CPM dates.
- Baseline calendars not updated: if a project calendar is modified after a baseline is set, the baseline dates remain anchored to the old calendar, making schedule variance comparisons unreliable.
Summary
When scheduling across multiple calendars in P6, you should always verify the following:
- Confirm the lag calendar setting in Tools | Schedule | Options | General (successor vs predecessor calendar) and document it in your schedule basis memorandum.
- Check that all activities have an intentionally assigned calendar and not just the default project calendar inherited at creation.
- Review activities near calendar boundaries (weekends, shift changes, holiday periods) where forward/backward rounding may introduce unexpected float.
- When comparing float across activities on different calendars, convert to calendar days for a meaningful comparison.
- After adding or modifying calendar exceptions (e.g. holidays, shutdowns), reschedule and check the impact on the critical path before distributing the updated schedule.
- For contractual milestone reporting, trace the driving path to the milestone in calendar days, not working days, to confirm the true constraint.