Data date
Last reviewed 9 September 20262,188 words10 min read
The single most misunderstood field in P6
🟩 In one line The data date is the moment the schedule stops describing the past and starts predicting the future. Everything to the left of it happened. Everything to the right of it hasn't. If that line is in the wrong place, every date in the file is wrong — and the file won't tell you.
👤 Who this is for Junior planners doing their first few updates. Anyone who has ever hit F9 and watched the whole schedule slide a month to the right for no reason. Senior planners preparing a delay analysis, where the data dates of the historic updates are the windows.
First, let's be honest about why this page exists
The data date looks like the least interesting thing in the program. It's one field, on one tab, and it only changes once a month. Most people learn it as a chore: "before you schedule, move the data date." Done.
Then something odd happens. The forecast finish jumps two weeks after an update where nothing slipped. Or an activity that finished last Tuesday still shows as remaining. Or the client's reviewer sends back a comment saying "actual dates after data date — reject," and nobody in the office is sure what that means or why it matters.
All of those come from the same place. The data date isn't a formality. It's the one assumption every other calculation is built on. So it's worth understanding properly, once, and then never having to think about it again.
🟨 The standard — what "good" looks like
The data date (also called the status date or time now) is the date up to which progress has been recorded. Actual dates fall on or before it. Remaining work is scheduled on or after it. P6 begins the forward pass from the data date, not from the project start.
What the standards expect:
- AACE RP 53R-06 (Schedule Update Review) and the PMI Practice Standard for Scheduling both treat the data date as the reference point for every update: progress is measured to it, forecasts are calculated from it.
- DCMA 14-Point, Metric 9 (Invalid Dates) — no actual dates after the data date, no forecast (early) dates before it. Zero tolerance. This is the single most common reason updates get rejected.
- GAO Schedule Assessment Guide, Best Practice 8 — the schedule must be updated regularly with a consistent status date, and all remaining work must be scheduled after it.
- Gulf client specifications almost always fix the monthly cut-off — typically the 25th, sometimes the last calendar day — and require the data date in the submitted XER to match it exactly. Not the day you did the update. The cut-off.
Three rules, and they're absolute:
- Nothing actual after the data date. If it hasn't happened by the data date, it hasn't happened.
- Nothing remaining before the data date. If it hasn't finished, its remaining work starts at the data date, not last week.
- One data date per update, and it never goes backwards.
How it actually works
Think of the data date as the shutter on a camera. You point it at the project on the 25th and press the button. The photograph shows exactly what was true at that moment — what was done, what was half done, what hadn't started. That's the update.
Everything the schedule then predicts is calculated from that photograph forwards. So if you've pressed the shutter in the wrong place, the prediction starts from the wrong moment.
What P6 does with it
When you schedule (F9), P6 goes to Project → Dates → Data Date and starts the forward pass there. Any activity that hasn't started gets an early start of the data date at the earliest — even if the logic would have allowed it to start six weeks ago. Any activity that has started but not finished gets its remaining duration scheduled from the data date.
That is why, when you move the data date forward without statusing anything, the whole unstarted schedule slides right by the same amount. P6 isn't being pessimistic. It's being literal: you've told me it's now the 25th and none of this has started, so none of it can start before the 25th.
Where it hides
- Project → Dates tab → Data Date — the field itself.
- Tools → Schedule (F9) — the dialog shows the current data date and lets you change it before running. Most planners set it here.
- The vertical blue line on the Gantt chart. If you can't see one, turn it on under View → Bar Chart Options → Sight Lines. Never work without it visible.
- The time of day matters more than people think. A data date of 25 March 00:00 and 25 March 17:00 are a full working day apart. Set it consistently — usually the start of the working day after the cut-off, or the end of the cut-off day — and write which one you use in the basis memo.
What it does that people don't expect
- Level of Effort activities recalculate against it. Their duration stretches or shrinks to match their linked activities as of the data date.
- Earned value is measured at it. Planned value is read from the baseline at the data date; earned value is what's been achieved by it. Move the data date and the SPI changes even if progress doesn't.
- Baseline comparison is anchored to it. "Days behind baseline" means "as of the data date."
- Delay analysis uses it as the boundary between windows. When someone builds a windows analysis two years later, your monthly data dates are the windows. If they were inconsistent, the analysis is harder and weaker.
🟥 Where people go wrong
1. Forgetting to move it. The update is done, actuals are in, F9 pressed — and the data date is still last month. P6 accepts every actual date after the data date with nothing but a note buried in the schedule log. The forecast now starts a month too early and looks wonderful. The client's reviewer runs a check, finds forty actual dates after the data date, and rejects the whole thing.
2. Moving it before statusing. Data date jumps to the 25th, then you start entering progress. Meanwhile every activity that started in the period but hasn't been statused yet gets pushed to the 25th. If you get distracted and schedule halfway through, the dates are wrong and you may not notice which ones. Status first. Move the data date last. Then schedule.
3. Using the day you did the update instead of the cut-off. Progress collected up to the 25th, update done on the 2nd, data date set to the 2nd. Now there's a week of "no progress" in the file that isn't real — the site worked, you just didn't record it. Data date = cut-off. Always.
4. Ignoring the time. Cut-off is "end of 25th." Data date entered as 25th at 00:00 — the P6 default on a fresh project. Every activity that actually finished on the 25th is now "after the data date." Set the time to match what the words mean.
5. Leaving remaining work before the data date. An activity started in February, was 60% done, and site says it's still 60% — nothing happened. If you don't touch it, its remaining duration is still scheduled from where it was last month, which is now in the past. P6 will drag it to the data date when you schedule, but only if you schedule. This is one reason to always read the schedule log after F9.
6. Letting the data date drift between reports. Cut-off on the 25th one month, the 28th the next, the 22nd after that because Eid. Fine for internal management. Bad for the record. Every one of those inconsistencies becomes a footnote in a delay analysis later. If the cut-off has to move for a holiday, move it in the spec, not on the day.
7. Confusing it with "today." The data date is not the current date. It is the date the progress information is current to. P6 doesn't care what day it is when you press F9.
⚖️ When you're challenged
"Why did the finish date move two weeks? Nothing slipped." Check three things in this order: did the data date move more than a month; were all the activities that started in the period actually statused; are there activities with remaining duration that nobody updated. Usually it's the second one — a batch of activities got pushed to the data date because nobody told P6 they'd started. "Twelve activities on Level 4 started in the period but weren't statused. They got pushed to the data date. I've got the site diary; give me an hour."
"The client says 'actual dates after data date' — what do they mean?" Open Tools → Schedule → View Log after scheduling. There's a section listing exactly those activities. Someone typed an actual finish of the 27th when the data date is the 25th. Either the date is wrong or the data date is. Fix whichever is wrong, reschedule, resubmit. Don't argue about it; it's a mechanical check and they're right.
"Can we set the data date to the 1st instead of the 25th? It's cleaner." Only if the contract or spec allows it and the client agrees in writing. The point of a fixed cut-off is consistency across three years of updates. Changing it once is fine. Changing it because "it's cleaner" is how you end up with windows of 23 days and 38 days in the same analysis.
"We missed the cut-off. Can we just use last month's data date and add the new actuals?" No. That's two months of progress against one data date, and every actual in the second month is "after the data date." Do the update properly with the correct cut-off, even if it's late. A late update is a small problem. A wrong one is a permanent one.
📄 Related pages
- Statusing a schedule — the order to do the update in, so the data date is the last thing you touch
- Monthly update checklist — the one-pager, with the data date checks on it
- Out-of-sequence progress — what happens when actuals arrive in an order the logic didn't expect
- Retained logic vs progress override — the other setting in the F9 dialog that changes your dates
- Earned Value Basics: SPI and CPI — why PV, EV and SPI all depend on where the data date sits
- Windows analysis — how your monthly data dates become someone's delay analysis later
✏️ Worked example
A single activity, to show how much the data date alone changes.
Activity A210 — Transformer set on plinth. 3 working days. 6-day calendar. Predecessor is the delivery, which finished on 14 March. Contract cut-off is the 25th of each month, end of day.
Case 1 — done right. Site confirms A210 started 16 March, finished 18 March. Data date set to 25 March, 17:00. Schedule.
| Field | Value |
|---|---|
| Actual start | 16 Mar |
| Actual finish | 18 Mar |
| Remaining duration | 0 |
| Successor (cable pull) early start | 19 Mar — but it's now before the data date, so it shows as either started (if statused) or pushed to 26 Mar |
Case 2 — data date not moved. Same actuals entered, but data date left at 25 February. Schedule.
P6 accepts the actuals. The schedule log quietly notes "Activities with actual dates after data date: 1." The cable pull, if unstatused, is scheduled from 19 March as if that were the future. The forecast looks a week better than reality, and the file fails DCMA Metric 8.
Case 3 — data date moved before statusing. Data date set to 25 March first. Planner gets interrupted. A210 still has no actuals. Schedule.
A210 is pushed to start 26 March. So is everything behind it. The energisation milestone shows −8 days float. The PM sees it on the shared drive, panics, and calls a meeting about a delay that doesn't exist.
Case 4 — wrong time of day. Actuals entered correctly. Data date set to 25 March, 00:00. A different activity, A130 backfill, genuinely finished on the 25th at 14:00. Schedule.
A130's actual finish is now after the data date. Metric 8 fails on one activity. The reviewer rejects the update for a timestamp.
Four ways to handle one field. Only one of them produces a schedule that's true.
📖 References
- DCMA, 14-Point Schedule Assessment — Metric 9 (Invalid Dates)
- US GAO, Schedule Assessment Guide (GAO-16-89G) — Best Practice 8 (Updating the Schedule)
- AACE International, RP 53R-06, Schedule Update Review — As Applied in Engineering, Procurement and Construction
- PMI, Practice Standard for Scheduling, 3rd ed. — §5 (Schedule Maintenance)
- Oracle, P6 Professional User's Guide — "Data Date"; "Schedule Log"
From the field
Experience from working planners. Unreviewed — read it as experience, not guidance.
Add what you know about data date. What worked, what the consultant pushed back on, what you would do differently next time. A paragraph is plenty.
Contributors get their name and one link on the site — your own templates, course or consultancy. We take nothing and hold nothing.
Add your experience