Learning Center

Why Native Schedule Comparison Can Miss Calendar Changes

A comparison that only checks each activity’s own fields—dates, duration, relationships—can report an activity as completely unchanged even while its calculated dates shifted underneath it. The cause lives one level up, in the calendar the activity is assigned to.

Dates Are Calculated, Not Stored in Isolation

Every activity in a P6 schedule is assigned to a work calendar -- a defined pattern of working days, non-working days, and exception dates (holidays, planned shutdowns). An activity’s early/late dates and duration in calendar days are calculated by working forward or backward through that calendar’s own working-day pattern, not stored as some fixed number of days independent of it. Change the calendar, and every activity using it recalculates -- without a single field on the activity itself (its duration in hours, its predecessors, its relationships) ever actually changing.

Worked Example: One Holiday, Twelve Activities

A project’s “5-Day Standard” calendar originally has no closure planned for the week of Thanksgiving. Partway through the project, the scheduler adds a 4-day holiday exception (Thursday through Sunday) to that calendar to reflect an actual site shutdown.

Twelve activities are assigned to the 5-Day Standard calendar and still in progress or not yet started.
Every one of them recalculates with 4 fewer available working days between now and their finish -- pushing each one’s early finish date back by up to 4 calendar days (less if the activity had enough total float to absorb some of it).
Not one of those twelve activities has a changed duration, a changed predecessor, or a changed relationship. The only thing that changed anywhere in the schedule is the calendar’s own exception list.

One exception added to one calendar reaches all twelve activities assigned to it -- each shifts its own calculated dates without any activity-level field changing at all.

A comparison tool that diffs the TASK table’s own fields between two exports will correctly show each activity’s dates moved -- but if it stops there, it has no way to explain why twelve unrelated activities all shifted by up to 4 days at once. Without also comparing the CALENDAR table itself, the honest answer “a calendar exception was added” is never available -- only the symptom, not the cause.

Claims Digger’s comparison explicitly diffs calendars as their own object -- matched by name across two snapshots, not by an internal ID that can differ between exports of the same named calendar -- reporting added or removed exception dates and changed working-day patterns directly, alongside the activity-level diff. See how it works.

Frequently Asked Questions

Why would anyone change a calendar mid-project?: Legitimately, all the time -- adding a holiday closure that wasn't originally scheduled, switching a calendar to 6-day weeks to recover time, or correcting a calendar that was set up wrong at baseline. The point isn't that calendar changes are suspicious, it's that they're easy to miss if a comparison tool isn't looking at the calendar table at all.
Does a calendar change always affect every activity that uses it?: Yes, by definition -- every activity assigned to that calendar recalculates its dates against the new working-day pattern. That's exactly what makes it powerful (and risky) compared to editing one activity's duration: one calendar edit can shift dozens of activities' dates at once, all without a single one of them showing a duration or relationship change.
How do I know if two schedules are even using calendars with the same name?: Match by calendar name, not by the internal calendar ID -- P6 can assign a different internal ID to what is, for practical purposes, the same named calendar across two separate exports, so comparing IDs directly can wrongly report a calendar as 'deleted and re-added' when nothing about it actually changed.

Part of the Claims Digger Learning Center. Related reading: WBS rename false positives · Full glossary